In my opinion NFS actually works fine for realistic cases, once a couple of bugs are fixed and some other tools are put in place.
In real cases, the user logins in with a principal username@DOMAIN. That is always placed in the default collection defined in /etc/krb5.conf. At least for us, they may at times get additional credentials. I guess they could also change to a different collection. But they’ll always have their primary credential in the default collection unless they do something really silly. Our renew daemon will make sure it’s renewed as long as they have an active process (and it’s killed within 5 min after they logout). The NFS mechanism wants a credential username@DOMAIN. I think that’s perfectly sensible. And in any real cases the user will have such a credential when they’re logged in, whatever other credentials he may also have. GSSAPI by default will look through the default collection (I think also some other places). The problem is that the code in rpc.gssd works as followers: * get the default credential from the collection * fail unless it’s username@DOMAIN If you replace the initial step by code telling it explicitly to get username@DOMAIN then it works just fine, assuming that the user actually has such a credential. Which they will. GSSAPI is perfectly capable of looking for a specific credential if you tell it to. It’s just that the code doesn’t do it that way. To avoid building my own copy of rpc.gssd, I use a loadable library to interpose code around GSSAPI that supplies the right argument. The second case of interest is running cron jobs. In that case you will unfortunately have to trust root. It’s hard to imagine any way of running cron jobs that root couldn’t find a way to simulate. (well, actually there is. You could have a central cron server that ssh’s the command to the system. I think somebody does it that way. We might consider it.) So we allow users to register the fact that they trust root on a specific system. That fact is registered in LDAP. A pam module for cron does a kerberized call to a daemon on the KDC which verifies that root on that system is authorized, and returns a non-forwardable ticket for the user locked to that host’s IP(s). (It uses an MIT version of kimpersonate.) It is placed into a file in /tmp, which rpc.gssd checks if GSSAPI doesn’t find anything. The third case of interest is sshd. Sshd for some reason insists on putting credentials in a /tmp file, even if the default ccname is set to a collection. rpc.gssd would find it there. But if the user knits with a different principal, it will overwrite the original. So we really want the login credentials to go into a collection. We have a pam module that normalizes the credential cache at login. If /etc/krb5.conf asks for KEYRING or KCM, and the cache is in /tmp, the pam module copies it to the right place and deletes the original. I don’t have any issues with this. We did have lots of frustrations in the beginning. System staff would kinit to another principal to do administrative work and lose access to their files. Once we realized we needed the default ccname in /etc/krb5.conf to be a collection, and did these various fixes, things have worked fine. Now if I could get the maintainers of rpc.gssd and sshd to take my fixes … But really, to get transparent results you probably need our whole set of tools, since you’ll need the renew daemon, the stuff to generate credentials for cron, the pam modules, etc. On Jul 22, 2019, at 3:22 PM, Greg Hudson <ghud...@mit.edu<mailto:ghud...@mit.edu>> wrote: Taking a step back: I'm guessing the use case here includes NFS. The architecture of Linux NFS and of Kerberos ccaches have unfortunately never fit together in a very satisfactory way. The NFS userspace daemon wants to know what credentials are available to a user, knowing only its uid, while credential cache types are typically designed to provide flexibly named containers, not necessarily restricted to a single place per user or even restricted to use by one user. ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
