Re: pam_krb5 and user logout

[Mike Gerdts <Michael Gerdts usa alcatel com>]

On Wed, 2002-01-30 at 13:24, Nicolas Williams wrote: 

> How's this?
> 
> ...
> seteuid(user's uid);
> newfilename=mkstemp("/tmp/krb5cc_uid_XXXXXXXX");
> krb5_cc_default(...);
> krb5_cc_store_creds(...);
> link("/tmp/krb5cc_uid", newfilename + "_foo");
> rename(newfilename + "_foo", newfilename);
> ...

Looks pretty good.  krb5_cc_store_creds() stores them to
/tmp/krb5cc_uid, right?  Does krb5_cc_store_creds create a temp file
then rename?  If so, it will brek this.  (If I were writing
krb5_cc_store creds, I would have written in such a way that it would be
incompatible with this.) 

> Nah. mkstemp() takes care of that for the $newfilename.

Getting back to the original proposal: 

    If it is the first login, create /tmp/krb5cc_uid and create a hard
    link to some other file, /tmp/krb5cc_uid_XXXXXXX. 
    
    If it is not the first login, just create the hard link
    /tmp/krb5cc_uid_XXXXXXX. 
    
    If it is not the last logout, just remove my credential cache,
    /tmp/krb5cc_uid_XXXXXXX. 
    
    If it is the last log out, remove my /tmp/krb5cc_uid_XXXXXXX and
    /tmp/krb5cc_uid. 

If you have a last logout and a new login happening at the same time,
you could have a situation where the logout removes /tmp/krb5cc_uid
between the time that a login sees that it is there and the time that it
tries to create its _foo file. 

Since a lock looks like it will be necessary anyway, perhaps the best
way is to just have a file that sits next to /tmp/krb5cc_uid that is
used as a reference counter.  Either each login and logout could
increment or decrement a number in the file, logins and logouts could
enter some identifying information (tty if allocated, pid of toplevel
shell, etc.), with each line representing one session. 

> > That is an inherent problem with Sun's requirement that for GSS-API to
> > work you need to have a consistent file name.  It would be nice if the
> > pam module could send a message to gssd saying "uid 500 is using
> > /tmp/krb5cc_500_ab8923fs".
> 
> Yes. Interestingly enough that seems to be how ktwarnd works. Go figure.
> But, if Sun makes such a local IPC protocol for passing ccaches to
> gssd then I'm stuck with their PAM_KRB5, something I don't currently
> want.

I have a couple reasons of my own.

Bug 4508923 - Supposedly fixed in Sol9 build 54.  No word on 7 or 8.
Bug 4406541 - Supposedly fixed in Sol8 109805-05.  No word on 7.

These two bugs are the pam-related ones that keep me from running purely
Sun kerberos.  Pretty much every other part of Sun's implementation also
has some rather old (5+ months) showstopping bugs that make MIT's
kerberos rather attractive.

Mike