On Wed, Jan 30, 2002 at 11:23:42AM -0500, Mike Gerdts wrote:
> 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.)
Well, that was pseudo-code.
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);
...
> 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
The MIT krb5 cc stuff already does locking.
> 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.
Nah. mkstemp() takes care of that for the $newfilename.
> > > 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".
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.
> Mike
Nico
--
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-
Visit our website at http://www.ubswarburg.com
This message contains confidential information and is intended only
for the individual named. If you are not the named addressee you
should not disseminate, distribute or copy this e-mail. Please
notify the sender immediately by e-mail if you have received this
e-mail by mistake and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free
as information could be intercepted, corrupted, lost, destroyed,
arrive late or incomplete, or contain viruses. The sender therefore
does not accept liability for any errors or omissions in the contents
of this message which arise as a result of e-mail transmission. If
verification is required please request a hard-copy version. This
message is provided for informational purposes and should not be
construed as a solicitation or offer to buy or sell any securities or
related financial instruments.
