What's more, if I obtain (as root for example) a ticket for user mamalos and kdestroy it, and then login as user root in a new terminal, the root user in the new terminal has still all privileges of mamalos in the share. Klist, of course, shows no tickets. This could be also a security threat, in case different kerberos principals (users in this setup) use a shared machine account to logon, and then access their resources by kiniting to their respective principals. I assume that this must have to do with kernel's KGSSAPI support, which "forgets" to delete or renew its kerberos' cache. Thank you all, again, for your time. -- George Mamalakis IT Officer Electrical and Computer Engineer (Aristotle Un. of Thessaloniki), MSc (Imperial College of London) Department of Electrical and Computer Engineering Faculty of Engineering Aristotle University of Thessaloniki phone number : +30 (2310) 994379
On Fri, 5 Feb 2010, George Mamalakis wrote:> shows no tickets. This could be also a security threat, in case different > kerberos principals (users in this setup) use a shared machine account to > logon, and then access their resources by kiniting to their respective > principals. >The kernel only knows the effective uid and the current gssd assumes that there will be "one" user principal with a TGT in /tmp/krb5cc_N (where 'N' is that uid#). Having multiple principals sharing the same login/uid (which I'm guessing is what you refer to as a "shared machine account", isn't going to work. I suppose that the gssd could do a "uid"->"username"->"principal name" mapping and then use that "principal name", but it is still going to be unique (ie only one) per uid. rick
On Fri, 5 Feb 2010, George Mamalakis wrote:> > I assume that this must have to do with kernel's KGSSAPI support, which > "forgets" to delete or renew its kerberos' cache. >Oops, missed this on the last reply. It is actually a cache of "handles" for RPCSEC_GSS credentials allocated by the server (one per uid). It is normally the server that decides to expire them (they no longer really have anything to do with Kerberos, except that they were acquired via a Kerberos ticket and it uses the session key created by Kerberos). As noted before, I believe that kdestroy should somehow invalidate these handles (it's an RPC to the NFS server + flushing the cached entry in the client). A quick and dirty hack that has kdestroy do a system call to do this could be implemented fairly easily. A key management subsystem (aka key ring) that deals with all types of authentication and not just Kerberos would be much more work. rick