krb5 library missing functions for collections

[Charles Hedrick]

Ok. I see Simo’s point about laptops. I say current behavior is broken because when the context needs to be renewed it uses whatever principal is currently primary. So from a users point of view their access can change or break randomly.

Given the current kernel support the only thing reasonable is probably the ability to set policy.

Incidentally on a single user laptop you can actually do that. Rpc.gssd used .k5identity in root. On a single user machine that’s actually potentially useful.

Sent from my iPhone

On Jul 26, 2019, at 9:09 AM, Charles Hedrick <hedrick at rutgers.edu<mailto:hedrick at rutgers.edu>> wrote:

I’ve thought a bit more about this. i think the problem is that there’s no way to know what the user wants, and to really give him proper control requires significant kernel work.

Currently the Linux kernel establishes an NFS security context that is associated with the UID. Any process running with that UID uses that context.The context is long-lived, by default. The only sane choice is to use the main principal associated with the user. Using the principal that happens to be primary when the first access is done in simply broken.

I can think of two kinds of exception. Suppose I become root. I’d like to copy a program I just built to /usr. I need root to put in on user, but when I change UID, I lose access to my home directory. For this case perhaps it would be better if NFS used the current principal. Then I’d have a UID of root for local access and a principal of hedrick for NFS access. This would require a lot of kernel work, though. You’d need NFS security context based on the principal, and the kernel would have to look at KRB5CCNAME for every process doing an access, figure out the current principal, and use the right context.

But suppose we did that. Consider another case. I’m administrator of a number of services. Those services each require me to kinit as a specific principal. So now my current primary principal is hadoop or ldap-admin. If you use the current principal, I again lose access to my files.

I think a real solution involves a separate kernel attribute for the principal to use for NFS. Indeed it might need to be filesystem-specific, though in practical cases maybe not. (You’d also need to consider how to do idmap in that case.)

But none of these kernel changes exist. As long as the kernel does access based on UID, the only sane choice for rpc.gssd is the principal associated with my username. That means current behavior is broken. I now have a ccselect plugin to fix that. It has to be configured in /etc/krb5.conf. You can’t do it in ~/.k5identity. rpc.gssd ignores that, for good reason. If my home directory is on Kerberized NFS, I can’t access ~/.k5idenity until I’ve established a security context, so you can’t use ~/.k5identity to do that.

I’ve submitted a feature request to fix the default ccselect plugin so it reads /etc/k5identity if the user doesn’t have one or it doesn’t apply. Also, you’d need to recognize ${username}. That would let me specify a policy for NFS credentials, which could conceivably even differ for different file servers. I think that’s the best that can be done with the current kernel.


On Jul 22, 2019, at 3:22:19 PM, Greg Hudson <ghudson at mit.edu<mailto:ghudson at 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.