|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #73103 Release 1.1.0 has random behaviour
Submitted: 2016-09-17 11:27 UTC Modified: 2016-09-19 15:48 UTC
From: tvdijen at gmail dot com Assigned: cmb (profile)
Status: Closed Package: PECL (PECL)
PHP Version: Irrelevant OS: CentOS 7 + RHEL6
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: tvdijen at gmail dot com
New email:
PHP Version: OS:


 [2016-09-17 11:27 UTC] tvdijen at gmail dot com
The doAuthentication-method sometimes fails to return anything (execution stops).
It actually fails more often than it works. This behaviour started after updating the krb5-module to the latest release 1.1.0.

I started debugging my php-code by adding debug-lines. It turned out that code-execution stops at doAuthentication for no obvious reason. No errors are being displayed or even logged.

See example-code below. When I start IE and run the test-script, it will fail with a 'Page cannot be displayed'. Apache access log shows that the page request is received. I can see my own debug-lines in the logs up to doAuthentication() and then I run into a dead end.
When I repeat the test (close IE completely, start it again en run the script again), let's say one in ten times it fails.

A rollback to version 1.0.0 of the module fixed everything, so my guess is that the recent changes have something to do with this random behaviour. I've seen this behaviour on both RHEL6+PHP5.3 and CentOS7+PHP5.4

Test script:
 if(!extension_loaded('krb5')) {
         die('KRB5 Extension not installed');

        list($mech, $data) = explode(' ', $_SERVER['HTTP_AUTHORIZATION']);
         if(strtolower($mech) == 'basic') {
                 echo "Client sent basic";
                 die('Unsupported request');
         } else if(strtolower($mech) != 'negotiate') {
                 echo "Couldn't find negotiate";
                 die('Unsupported request');
         $auth = new KRB5NegotiateAuth('/path/to/keytab');

         if($reply = $auth->doAuthentication()) {
                 header('HTTP/1.1 200 Success');
                 echo 'Success - authenticated as ' . $auth->getAuthenticatedUser() . '<br>';
         } else {
                 echo 'Failed to authN.';
 } else {
         header('HTTP/1.1 401 Unauthorized');
         header('WWW-Authenticate: Negotiate',false);
         echo 'Not authenticated. No HTTP_AUTHORIZATION available.';
         echo 'Check headers sent by the browser and verify that ';
         echo 'apache passes them to PHP';

Expected result:
I'd expect doAuthentication() to at either return true/false or throw an error.

Actual result:
Code execution stops for no apparent reason.


Fix_insufficient_memory_allocation (last revision 2016-09-17 16:20 UTC by tvdijen at gmail dot com)

Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2016-09-17 11:39 UTC] tvdijen at gmail dot com
This should be connected to the krb5-module:
It somehow failed to do so.
 [2016-09-17 12:25 UTC] tvdijen at gmail dot com
I was also able to lift this error from /var/log/httpd/error.log:

[Sat Sep 17 14:22:10.007578 2016] [core:notice] [pid 2914] AH00052: child pid 2920 exit signal Segmentation fault (11)
 [2016-09-17 14:57 UTC] tvdijen at gmail dot com
Yet another update:
I've managed to narrow it down to the strcpy lines at the bottom of the doAuthentication-function. Specifically the second one.
Whenever I put in a RETURN_TRUE; above these lines, everything is working fine. When I put it underneath, de segfault is showing up again.
 [2016-09-17 16:15 UTC] tvdijen at gmail dot com
Proposed fix:

This fixed the problem for me. I think it needs space for a trailing null-character.
 [2016-09-17 19:17 UTC] mbechler at eenterphace dot org
Commited a fix to SVN. Thanks for the patch, but I don't think it's
quite right - the problem is that the base64 encoded buffer is not zero
terminated anymore after the 1.1 changes (wrapping in zend_string) so
the strcpy overflows the allocated buffer (the size is correct). Fixed
that by properly using strncpy.

I guess this can be closed (and if someone can tell me how to get a bug category and developer access to it, that would be great).
 [2016-09-18 10:54 UTC] tvdijen at gmail dot com
-Status: Open +Status: Closed
 [2016-09-18 10:54 UTC] tvdijen at gmail dot com
Thanks Moritz!
 [2016-09-19 15:48 UTC]
-Package: *General Issues +Package: PECL -Assigned To: +Assigned To: cmb
 [2016-09-19 15:48 UTC]
> and if someone can tell me how to get a bug category and
> developer access to it, that would be great

For the latter, you'd have to request a PHP Git account, see

With regard to the former, it *might* be helpful to file a
respective bug report.
PHP Copyright © 2001-2020 The PHP Group
All rights reserved.
Last updated: Wed Jul 08 02:01:27 2020 UTC