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
<[email protected]<mailto:[email protected]>> 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 [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos
