On Wed, Jan 30, 2002 at 02:33:27PM -0500, Mike Gerdts wrote: > 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.) Oh dear, I forget. another thing to check. > 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. Well, kdestroy /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. Tough. > 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. This is getting too complicated. It would all be much simpler if there were an IPC API for passing new ccaches to gssd (an open interface too). > > > 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. Yup. I so agree. We took a look at Sun's PAM_KRB5 in 2000 and quickly ditched it in favor of hacking Frank Cusack's into the shape we needed it in, which we did and we're very happy. > 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.
