ehough
commented
4 years ago Thanks for your detailed question. I'll do my best to help!
NFS & RPC are kind of alien technology to me, my problem could be an obvious mistake
You're not alone. In my opinion NFS is poorly documented, especially considering its popularity. It's often difficult to find clear answers to seemingly easy questions. And the RFCs are lengthy and as clear as mud.
I can mount my share, and I can browse it if (and only if) my user has a ticket. So I guess that my Kerberos configuration is fine.
Yep, that sounds like your Kerberos basics are in place and working as expected.
Important fact: All of this in NFSv3
I think this is the root of the problem. I don't consider myself to be an expert by any means, but here's my understanding of the situation:
- NFSv3 servers can use
sec=krb5*in their export definitions to provide a binary ("yes" or "no") authorization based on whether or not the client is Kerberos-authenticated - NFSv3 without Kerberos, simply speaking, sends the client UID in requests and the server interprets that as is. So UID 1000 on a client is interpreted as UID 1000 on the server.
- NFS (v3 or v4) with Kerberos instead sends the client's Kerberos principal in requests. So the NFS server will see e.g.
foo@bar.comas the client user and will try to map it to a local user. - NFSv3 does not define a means to map a client Kerberos-authenticated user to a server-local user. A client request from
foo@bar.comdoesn't really make sense to an NFSv3 server, so it squashes the request to the anonymous user or whatever user is defined forall_squash. I think this is what's happening in your setup. - NFSv4 servers exclusively use "client names" (e.g.
user@somedomain.com) in requests and useidmapdto map the incoming client names to server-local users. So given an request from userfoo@bar.com, the server would askidmapdfor the local system user and then use that result for authentication/authorization purposes.
Clear as mud, right? In summary, I don't think NFSv3 + Kerberos is capable of providing the "fine-grained" user authentication/authorization that you need.
kamarov18
Thank you for this nice and useful project!
Unfortunatily, I'm stuck and desperate because of Kerberos .. I've followed the instructions to configure the container (created a keytab for the service, etc.). I can mount my share, and I can browse it if (and only if) my user has a ticket. So I guess that my Kerberos configuration is fine.
The diagram illustrates my lab. All the Kerberos heavy lifting is done by the IPA server. The nodes are enrolled in the ipa, which provides in return the keytabs and the correct krb5.conf (I had to modify the one for nfs-server, because of some includes inside the file that where not available in the container).
BUT, all access from any users are "squashed". "root" or non-privileged user (it's an IPA' domain user, with very high UID like 20000), same effect, the server is seeing me as "nfsnobody". I've collected some debug of rpc.gssd on the client side, nothing seems suspicious: principals and UIDs are correct. On the server side, even with the container in DEBUG it's difficult to me to understand how rpc.svgssd works.. I see some "uid=-1" but I don't know if it's relevant.. I tried to "reproduce" the container outside of docker, but in my CentOS environment rpc.svcgssd seems to no longer exist (replaced by gssproxy).
If I don't use kerberos (without the flag), my users are linked to their legitim UID (reason for why I suspect kerberos).
Important fact: All of this in NFSv3, because .. legacy.
NFS & RPC are kind of alien technology to me, my problem could be an obvious mistake, so thank you for any advice, clue, explanation ..