On Tue, 2002-01-29 at 15:11, Nicolas Williams wrote:
> On Tue, Jan 29, 2002 at 01:37:21PM -0500, Mike Gerdts wrote:
> > Of course, this has to have some cooperation from things that may want
> > to update the credential cache with something like:
> >
> > open(/tmp/newfile)
> > write(newfile, data)
> > close(newfile)
> > rename(/tmp/newfile, /tmp/oldfile)
>
> ...
> seteuid(user's uid);
> newfile=mktemp("/tmp/krb5cc_uid_XXXXXXXX");
> krb5_cc_default(...);
> krb5_cc_store_creds(...);
> link("/tmp/krb5cc_uid", newfile);
> ...
>
As it is, this does not work. mktemp() creates a new file. The second
argument to link() must not exist, and as such link() would fail. That
is just am implementation detail... (Sorry, I've had recent contact
with someone from marketing. It rubbed off.)
What really needs to happen is every time that krb5_cc_* access the cc,
it needs to update /tmp/krb5cc_uid. Locking must be done on this file
to be sure that there are not multiple things trying to update it at the
same time. Presumably this locking is already done. Another type of
locking needs to be done around all the link() and unlink() calls to
guard against multiple login/logout events from stepping on each other.
> > Perhaps that last part is the deal breaker on this scheme.
>
> Not really, though with default ccache names there's the threat of
> symlink races...
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".
Mike
