The KEYRING mechanism is nice, in many ways. But it has some unexpected effects.
There’s a “primary” key for the usual keyring. But this is a global object. That is, which cache is primary is the same for all sessions, and for NFS. Imagine I’m a privileged user. I start out logged in as hedr...@cs.rutgers.edu<mailto:hedr...@cs.rutgers.edu>. I now decide to do some administrative work. I kinit as ad...@cs.rutgers.edu<mailto:hedrick.ad...@cs.rutgers.edu>. What happens depends upon exactly how KRB5CCNAME is set. Depending upon how I logged in, KRB5CCNAME may be set either to KEYRING:persistent:NNN or KEYRING:persistent:NNN:XXX. If it’s set to KEYRING:persistent:NNN:XXX, kinit will fail with an error "kinit: Can't create new subsidiary cache because default cache is already a subsidiary while generating new ccache.” Also, “klist -l” will fail. Actually, it will appear to work, but only show me the one cache even if there are others. If KRB5CCNAME is set to KEYRING:persistent:NNN, kinit will work. It will create a new cache for the new credentials, and make it primary. The problem with making it primary is that if NFS happens to check my credentials at that point it will fail. rpc.gssd uses a GSSAPI interface that only checks the primary credentials. Of course admin won’t mean anything to NFS, since my file access will all need to be done as hedrick. About the best I could come up with is to wrap kinit with a script that sets KRB5CCNAME to KEYRING:persistent:NNN before doing kinit, so it always works. It then does kswitch to switch back to my primary cache, so that NFS doesn’t break. Finally, it checks whether with my original setting of KRB5CCNAME I’ll see the cache I just set up. There’s a good chance I won’t. In that case it prints a command to set KRB5CCNAME appropriately, which I can cut and paste. I also have a skshow, which helps me switch between caches if I don’t need to reauthentication. “skshow principal” looks for a cache for that principal and prints a command line to set KRB5CCNAME appropriately. If anyone has better ideas I’d love to hear them. (I note that using FILE rather than KEYRING doesn’t produce results that are as surprising, but I’d still want wrapper scripts to help maintain multiple caches.) ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
