Re: PHP's ldap_sasl_bind tries to authenticate with KRB5CCNAME other than the one provided by mod_auth_kerb

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, May 2, 2007 9:41 am, gil ran wrote:
> I am using Apache-2.2.2 with mod_auth_kerb-5.3, php-5.2.1,
> openldap-2.3.27 cyrus-sasl-2.1.21 and heindal-0.7.2 on a
> Linux-from-scratch based system.
>
> The problem I'm presenting is probably a PHP issue or an Apache issue,
> or a mod_auth_kerb issue. I could not understand which one causes the
> problem.
>
> I am trying to connect using SASL and GSSAPI to the LDAP server from a
> PHP script that runs on the Apache server.
>
> The script (in short) does the following:
>   putenv("KRB5CCNAME=" . $_SERVER['KRB5CCNAME']);
>   echo getenv("KRB5CCNAME");
>   system("klist");

Always use 'exec' instead, and ALWAYS get the output and the error
code and ALWAYS ALWAYS ALWAYS check the error code!

>   $ldapconn = ldap_connect("ldap://example.org";) || die(...);
>   ldap_sasl_bind($ldapconn, NULL, NULL, "GSSAPI") || die(...);
>
> When I run the script manually from a shell that has a proper
> KRB5CCNAME environment variable, both the system("klist") and the
> ldap_sasl_bind(...) work as they should.

When you run the script manually from a shell, you are probably NOT
the same User as PHP runs as, and you are probably NOT using the same
shell either, and you therefore almost certainly do NOT have the same
environment for your test as for Reality.

This is like stunt-driving a car on a Closed Course with a
Professional Driver, and then pretending that it's safe to do that
same stunt on a busy city street... :-)

99.9% of the time, this problem boils down to:
paths and permissions

Use a FULL PATH for any file/program in your exec call:
NOT klist
/usr/bin/klist
/usr/local/bin/klist
/sharedhost/example.com/usr/local/i/compiled/it/myself/bin/klist

NOT somefile.txt
/full/path/to/wherever/it/lives/somefile.txt


> When I run `restart Apache' and then enter to the PHP page for the
> first time both work as well. The KRB5CCNAME written is
> /tmp/krb5ccname_apache_<something>

I dunno what klist does, nor what any of the KRB stuff is, but if you
want to preserve this KRB thingie from page to page, it looks like you
will need to do more than just run 'klist'...

You'll need to store the setting somewhere, transmit that storage
location through the stateless HTTP protocol (just like
GET/POST/COOKIE is used) and then retrieve it if it's already been
stored, or make a new one, as appropriate for whatever you are trying
to do, which I also don't really understand, but there it is.

> After that, each time I enter the page I get some other KRB5CCNAME
> (other than the one I got before), the system("klist") command works
> as it should, but ldap_sasl_bind returns "Local error". In this case I
> also get an error written to /var/log/auth. This error says that the
> file /tmp/krb5ccname_apache_<something> could not be found (this is
> the same <something> that was written by PHP after I restarted
> Apache). This means that the authentication process tries to use the
> previous file-name.

See above.

> I added a debug print to PHP's ldap_sasl_bind function that prints
> `getenv("KRB5CCNAME")' to Apache's error-log. The KRB5CCNAME written
> to the error-log is the same as the one PHP outputs. Not the one
> written to the auth log.
>
> Why isn't the KRB5CCNAME variable passed on?

Why should it be passed on?

Each "run" of your script is a totally separate process, and if you
have multiple Apache children, they each have their own process.

So unless you've got some magic wand to get them all to share (e.g., a
cross-process storage/communcation) they are not going to share.

> Which of the three (PHP, Apache, mod_auth_kerb) keeps the first
> KRB5CCNAME?

Yes.

:-)

If you are running PHP as CGI, it will never have the same KRB twice,
I suspect.

If you run PHP as Apache module, each Apache child and the related PHP
environment could easily keep its own KRB, I suspect.

I got no idea whatsoever what the kerb thing is doing, but as a
mod_xxx, it is also tied to the Apache child process, of which there
might be HUNDREDS.

If you are setting the ENV in the Apache startup with something in
httpd.conf or your Apache startup script, that would maybe share the
KRB across all children, but just setting it with PHP script won't
touch other children.

> How do I cause the new KRB5CCNAME to be used for authentication?

Hopefully I've outlined the issues enough above for you to know the
answer, even though I have no idea what the answer really is...

-- 
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some indie artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

-- 
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


[Index of Archives]     [PHP Home]     [Apache Users]     [PHP on Windows]     [Kernel Newbies]     [PHP Install]     [PHP Classes]     [Pear]     [Postgresql]     [Postgresql PHP]     [PHP on Windows]     [PHP Database Programming]     [PHP SOAP]

  Powered by Linux