On 5/3/07, Richard Lynch <ceo@xxxxxxxxx> 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
