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
