Opened 8 years ago

Closed 7 years ago

#70 closed defect (invalid)

Authentication fails (user and password garbled in xcache.c::xcache_admin_auth_check()?!)

Reported by: blueyed Owned by: moo
Priority: major Milestone:
Component: admin Version: 1.2-dev
Keywords: Cc:
Application: PHP Version: PHP_5_2
Other Exts: SAPI: FastCGI
Probability: Blocked By:
Blocking:

Description (last modified by moo)

I've just rebuilt PHP_5_2 and XCache from the 1.2 branch, but now the authentication for the admin pages fails.

I've added:
===================================================================
--- xcache.c    (Revision 357)
+++ xcache.c    (Arbeitskopie)
@@ -1558,6 +1558,8 @@
                pass = NULL;
        }

+               php_error_docref(NULL TSRMLS_CC, E_ERROR, "user: %s, password: %s", user, pass);
+               zend_bailout();
        if (user != NULL && pass != NULL && strcmp(admin_user, Z_STRVAL_PP(user)) == 0) {
                PHP_MD5_CTX context;
                char md5str[33];

And get something like:

Fatal error: xcache_count() [<a href='function.xcache-count'>function.xcache-count</a>]: user: äñT·`òT· ñT·\ÜT·, password: HòT·°òT·üñT·øàT· in /var/www/web7/web/xcache-admin/xcache.php on line 100
(The "binary blob" does change after a few request!)

Dumping $_SERVER itself in PHP does show the correct values for PHP_AUTH_USER and PHP_AUTH_PW.

I've configured XCache with just "./configure --enable-xcache --with-php-config=/usr/local/php52-fcgi/bin/php-config"

SVN trunk shows the same behaviour.

Maybe it's normal that the user/pass gets displayed as binary blob, when displayed like I've done it - but I would not expect it to change when I press F5 in the browser.

Change History (7)

comment:1 Changed 8 years ago by moo

  • Description modified (diff)
  • Status changed from new to assigned

analyzing

comment:2 Changed 8 years ago by moo

can't reproduce, can anyone help me to reproduce it?

comment:3 Changed 8 years ago by blueyed

I've now put a phpinfo()-page into the same directory, where the .htaccess/.htpasswd is and the following info is set and seems to be correct:

_SERVER["PHP_AUTH_USER"]
_SERVER["PHP_AUTH_PW"]
_SERVER["Authorization"]
_SERVER["REDIRECT_REMOTE_USER"]

Regarding "Authorization": I've patched PHP for this:

--- sapi/cgi/cgi_main.c 27 Feb 2007 03:28:17 -0000      1.267.2.15.2.29
+++ sapi/cgi/cgi_main.c 1 Mar 2007 19:34:14 -0000
@@ -969,7 +969,7 @@
                SG(request_info).content_length = (content_length ? atoi(content_length) : 0);

                /* The CGI RFC allows servers to pass on unvalidated Authorization data */
-               auth = sapi_cgibin_getenv("HTTP_AUTHORIZATION", sizeof("HTTP_AUTHORIZATION")-1 TSRMLS_CC);
+               auth = sapi_cgibin_getenv("Authorization", sizeof("Authorization")-1 TSRMLS_CC);
                php_handle_auth_data(auth TSRMLS_CC);
        }
 }

But I don't think that's the problem here!?

Is my "debug-patch" (the php_error_docref()-call mentioned in the report) supposed to print out the real values?

I've now rebuilt PHP_5_2 from current CVS, also xcache from 1.2 branch and even made sure that the libs in my chroot jail are up-to-date (I'm using makejail and have now added a call for php5-fcgi to the /xcache-admin/xcache.php file). This bails out now with:

Fatal error:  xcache_count(): user: (null), password: (null)

At least it's not garbled here.. ;)

Do you have any hints about how to debug this further?

comment:4 Changed 8 years ago by moo

home modified XCache/php is not supported, so is your modified version and hardened-php (but we planned to support hardened-php when it stop breaking abi, and most users start using the newer hardened patch)

suggestion: why do u have to remove HTTP_AUTHORIZATION to add Authorization? what if you keep HTTP_AUTHORIZATION not removed?

debug tips: add a var_dump($_SERVER); before xcache_count(..) to see what's in it.

i was using PHP_5_2 latest too

comment:5 Changed 8 years ago by blueyed

I need the patch, to have PHP_AUTH_* working at all - it seems to be related to using fastcgi. I've just reverted the patch, and then PHP_AUTH_* is not set at all, but only _SERVERAuthorization? is.
I've adjusted the fastcgi-config to:

FastCgiServer /XXX/php5-fcgi-starter -user X -group X -pass-header Authorization -pass-header HTTP_AUTHORIZATION -flush -idle-timeout 60

It seems that my Apache2 (2.0.55-4ubuntu2.1) uses Authorization instead of HTTP_AUTHORIZATION. I've filed a bug about this on bugs.php.net, but could not find it again.

I've added the var_dump($_SERVER) just before xcache_count() and it looks OK - just like using phpinfo() in the same directory.

comment:6 Changed 7 years ago by blueyed

Ok. First, my debug output had should used Z_STRVAL_PP() for user and pass.
E.g.,

php_error_docref(NULL TSRMLS_CC, E_ERROR, "user: %s, password: %s", Z_STRVAL_PP(user), Z_STRVAL_PP(pass));
zend_bailout();

After finding this out, I could debug this and it appears that this is no bug in xcache, but with my setup: I've used another password in the .htpasswd file than in xcache.admin_pass.

Sorry, please close as "Invalid".

comment:7 Changed 7 years ago by moo

  • Resolution set to invalid
  • Status changed from assigned to closed

thanks. sorry that i didn't figure out your wrong code

Note: See TracTickets for help on using tickets.