Nfs – CIFS and NFS: Permissions and underlying file systems

cifsnfspermissions

I have been doing a little reading, but am not completely clear still. My understanding is that NFS permissions are fairly black or white, and are controlled by the exports file (I believe there are options to have the local filesystem permissions be respected for the NFS client, but I typically don't see that used). the underlying filesystem doesn't delegate permissions for the NFS client. How does CIFS manage permissions? Do Windows ACLs or NTFS permissions control the client access? Does the underlying filesystem come into the picture?

Specifically, I am curious about copying files from an NFS share to a CIFS share. When using rsync -a, should the permissions be retained? Does it matter whether the underlying filesystem used inodes or not on either the NFS or CIFS share?

Best Answer

This is quite a broad question, and a bit depends on e.g. NFS versions.

However:

NFS allows you to specify a security mode on export. It also allows you to apply limits to which servers may mount your export. (Either limiting mounting at all, or enforcing read only/no root).

This is nothing at all to do with permissions. If your security mode is 'sys' that means the remote system decides how to handle authentication - you are delegating trust to your remote server - if the mounting client says 'hey, I'm UID 123' then your server trusts them.

It is possible to export NFS with Kerberos security mode, which is less trusting. It's not anywhere near as easy to get set up and working though, and as a result isn't used as much. However, Kerberos moves the trust relationship to a trusted server - A Kerberos Domain Controller. (Which if you know Windows better, is quite similar to a Window Domain Controller - that's no accident either).

With Kerberos, you need to authenticate via a third party, and your file accesses are then arbitrated in line with the permissions. NFS <= V3 allows the 'standard' user, group, other read/write/execute permissioning system. NFSv4 supports more detailed access control lists. These are also not used too widely, because they're more complicated.

When you come to CIFS though, you're approaching from a different angle. CIFS shares are all about the user context. Servers do not mount a CIFS shares, users map to it. Built into that are the CIFS user authentication. This is now (usually) done via Kerberos as well.

I present my user credentials (Kerberos ticket)* to the server, who can look at the share permissions to see if I may access it at all.

Separate from the share permissions are the filesystem permissions, which are also applied - once I've been authorised for share access.

I'm sure it'll come as no surprise that there's a degree of convergence between CIFS/Kerberos authentication and permissioning and NFSv4/Kerberos. Indeed, we're currently in the process of converging our hosting environments to use common permissioning.

However if you're not doing NFSv4, you still have to handle mapping between CIFS group/role based permissions and the Unix ones.

  • You don't have to be using Kerberos to speak to Windows - there's a change you're using NTLM. It's not a great plan, but works broadly the same way - at least from a permissions/share mapping perspective.
Related Topic