Re: [PHP] PHP's ldap_sasl_bind tries to authenticate with KRB5CCNAME other than the one provided by mod_auth_kerb
I think the problem you mention is located in the kerbero-lib. The Credential-cache is implemented as static and only set once per process (in a memeory area of the lib) Therefore, the first process of your apache will really set that variable and be able to authenticate to the kdc. Any following request handled by Any thread of that process will fail since the variable points to a now deleted (and wrong) credential-cache. As a verification you could limit the number of precesses, threads and the allowed request per process to 1 and try your code. I have the very same problem while connecting to LDAP and to postgreSQL using GSSAPI. A possible solution is discussed here: http://www.mail-archive.com/[EMAIL PROTECTED]/msg00350.html Regards, Thimo Langbehn -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP's ldap_sasl_bind tries to authenticate with KRB5CCNAME other than the one provided by mod_auth_kerb
My platform is basically debian sarge + heimdal gssapi, but I have exactly the same problem. I have a way to solve the issue, but it is not valid for any kind of production site. Just add in your php code this copy(substr($_SERVER['KRB5CCNAME'],5),/tmp/krb5cc_0); and you'll get a real bind (you see the ldap ticket with klist). I think that I must use the uid 0 for the credential cache because my apache master process is owned by root. If it did start with a different user, you probably need to change the '_0'. If you don't expect heavy usage and don't care about run conditions, you might use it as is. I might recommend some basic existence checks to avoid collisions and possible impersonation (In my case, different users have different persmissions on the ldap tree), but I believe it will not scale in any sensible manner. I'm afraid that this is due to the fact that mod-php (and php-ldap) is loaded during initialization, and looks like the credential cache value is either frozen or not taken from environment. I've tried to use putenv and apache_setenv, as well as manually fix $_ENV with no success, but I'm unsure if any of them have the same effect than export a shell variable, which is what is actually expect. -- View this message in context: http://www.nabble.com/PHP%27s-ldap_sasl_bind-tries-to-authenticate-with-KRB5CCNAME-other-than-the-one-provided-by-mod_auth_kerb-tf3681101.html#a10323750 Sent from the PHP - General mailing list archive at Nabble.com. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP's ldap_sasl_bind tries to authenticate with KRB5CCNAME other than the one provided by mod_auth_kerb
On Thu, May 3, 2007 12:33 am, gil ran wrote: 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'... I don't want to preserve this KRB thingie from page to page. The opposite is correct: I don't understand why the old file-name is used instead of the new one. How could GSSAPI know *which* Apache child's environment to check?... When using ldap_sasl_bind with the 4th argument set to GSSAPI we are trying to bind to the ldap server using sasl and GSSAPI. The GSSAPI ignores any provided username/password (authcid, for those of you who are familiar with sasl). Instead, it uses the information kept in the credential cache file. This is the file Apache (mod_auth_kerb) creates. This is the file-name provided by it in $_SERVER['KRB5CCNAME']. If you aren't passing it from Apache to GSSAPI, then it's going to snag whichever env happens to have been set last or... There's a differnt ENV floating around for each Apache child, I think, so how is GSSAPI supposed to know which one to snag? -- 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
Re: [PHP] PHP's ldap_sasl_bind tries to authenticate with KRB5CCNAME other than the one provided by mod_auth_kerb
On 5/3/07, Richard Lynch [EMAIL PROTECTED] wrote: On Thu, May 3, 2007 12:33 am, gil ran wrote: 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'... I don't want to preserve this KRB thingie from page to page. The opposite is correct: I don't understand why the old file-name is used instead of the new one. How could GSSAPI know *which* Apache child's environment to check?... I really don't know. I guess that's the main thing I want to find out. I guessed that the environment variable that is set (in the c) code just before calling ldap_sasl_interactive_bind_s would be used, but I was wrong (the auth log showed me that I was wrong). I'm sure that it is consistent. I'm sure of that because the same filename is written to the auth log each time. What you wrote got me to thinking that maybe Apache gets the request (that starts a new session), handles it, and then forks and lets the child to handle the session, although the parent process keeps handling GSSAPI calls. I tried to check this, but I didn't find how to get the ENV of all the httpd processes (I tried /proc/pid/environ, but it seems that it is not updated during runtime - it always contains the initial environment). This would probably tell me where GSSAPI could get the old KRB5CCNAME from. Do you know how to do this? When using ldap_sasl_bind with the 4th argument set to GSSAPI we are trying to bind to the ldap server using sasl and GSSAPI. The GSSAPI ignores any provided username/password (authcid, for those of you who are familiar with sasl). Instead, it uses the information kept in the credential cache file. This is the file Apache (mod_auth_kerb) creates. This is the file-name provided by it in $_SERVER['KRB5CCNAME']. If you aren't passing it from Apache to GSSAPI, then it's going to snag whichever env happens to have been set last or... There's a differnt ENV floating around for each Apache child, I think, so how is GSSAPI supposed to know which one to snag? Theoretically, each child has its own environment, and the different environments should not be accessible to the other children. This means that (again, theoretically), the process that created the PHP thread should pass its ENV to PHP that should pass it to ldap that should pass it to sasl that should pass it to GSSAPI. One of them seems to look at the environment of another process (probably the parent). How can this be? Shouldn't the operating system protect the processes? After all, ENV is a block of memory that belongs to a certain process. How come another process is able to access it? The only thing I can think of is that something along the way is created in shared memory, and used from all of the processes. In this case the first process that passed its ENV will win. This seems to get very far away from PHP. I'm starting to think that I should look for what ever it is that is not working/configured properly somewhere else. Up until now I looked at PHP and Apache. Now I'm starting to think that the source of this problem can be in openldap/cyrus-sasl/heimdal. I'm not sure. Any other ideas will be welcome. In the meantime I will ask the Apache, ldap, sasl and kerb experts as well... Thank, Gil Ran. -- 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
[PHP] PHP's ldap_sasl_bind tries to authenticate with KRB5CCNAME other than the one provided by mod_auth_kerb
Hi. 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); $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 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 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. 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? Which of the three (PHP, Apache, mod_auth_kerb) keeps the first KRB5CCNAME? How do I cause the new KRB5CCNAME to be used for authentication? Any ideas? Thanks, Gil Ran. P.S. I am not on the list, please cc me. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP's ldap_sasl_bind tries to authenticate with KRB5CCNAME other than the one provided by mod_auth_kerb
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
Re: [PHP] PHP's ldap_sasl_bind tries to authenticate with KRB5CCNAME other than the one provided by mod_auth_kerb
On 5/2/07, Richard Lynch [EMAIL PROTECTED] wrote: 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! This is not the full code. I did check error codes. Lets call this a summery of the code. The system command is meant to check if the KRB5CCNAME environment variable is the valid one when used with system. This proved that the variable was indeed passed in this case. $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 true. I tried from a shell (meaning, running from bash `php filename') in order to debug more easily, and found out that it always works this way. 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 But klist worked. As I said, the klist was added for debug purpose only. 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'... I don't want to preserve this KRB thingie from page to page. The opposite is correct: I don't understand why the old file-name is used instead of the new one. OK. I'll give some background about KRB5CCNAME, klist, etc. `klist' is a command that lists the tickets (credentials) that the current kerberos user holds. `KRB5CCNAME' contains the full path to a temporary file that holds the credentials data. This information is passed to the apache by the browser. The file itself is created by Apache (mod_auth_kerb). Apache (mod_auth_kerb) also initializes`KRB5CCNAME'. When using ldap_sasl_bind with the 4th argument set to GSSAPI we are trying to bind to the ldap server using sasl and GSSAPI. The GSSAPI ignores any provided username/password (authcid, for those of you who are familiar with sasl). Instead, it uses the information kept in the credential cache file. This is the file Apache (mod_auth_kerb) creates. This is the file-name provided by it in $_SERVER['KRB5CCNAME']. When using GSSAPI for authentication it reads the current credentials from the credential cache file. It knows where it is according to the environment variable `KRB5CCNAME'. In this case, for some reason, while KRB5CCNAME contains the correct value, GSSAPI is not using it. It is using some other value. 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. Not relevant. The problem is not that the data is not stored, it's that the data is stored when I don't want it to be. 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
