Managing NFS and NIS, 2nd Edition - Mike Eisler [154]
* * *
ACLs that deny access
We showed how we can prevent charlie from getting access to lucy's files by creating an ACL that included only linus and sally. Another way lucy could have denied charlie files is to set a deny entry for charlie:
% setfacl -m user:charlie:--- blockhead
No matter what the group ownership of blockhead is, and no matter what the other permissions on blockhead are, charlie will not be able read or write the file.
ACLs and NFS
ACLs are ultimately enforced by the local filesystem on the NFS server. However, the NFS protocol has no way to pass ACLs back to the client. This is a problem for NFS Version 2 clients, because they use the nine basic permissions bits (read, write, execute for user, group, and other) and the file owner and group to decide if a user should have access to the file. For this reason, the Solaris NFS Version 2 server reports the minimum possible permissions in the nine permission bits whenever an ACL is set on a file. For example, let's suppose the permissions on a file are 0666 or rw-rw-rw-. Now let's say an ACL is added for user charlie that gives him permissions of —-, i.e., he is denied access. When an ACL is set on a file, the Solaris NFS Version 2 server will see that there is a user that has no access to the file. As a result, it will report to most NFS Version 2 clients permissions of 0600, thereby denying nearly everyone (those accessing from NFS clients) but lucy access to the file. If it did not, then what would happen is that the NFS client would see permissions of 0666 and allow charlie to access the file. Usually charlie's application would succeed in opening the file, but attempts to read or write the file would fail in odd ways. This isn't desirable. Even less desirable is that if the file were cached on the NFS client, charlie would be allowed to read the file.[3]
This is not the case for the NFS Version 3 server though. With the NFS Version 3 protocol, there is an ACCESS operation that the client sends to the server to see if the indicated user has access to the file. Thus the exact, unmapped permissions are rendered back to the NFS Version 3 client.
We said that the Solaris NFS server will report to most NFS Version 2 clients permissions of 0600. However, starting with Solaris 2.5 and higher, a side band protocol to NFS was added, such that if the protocol exists, the client can not only get the exact permissions, but also use the sideband protocol's ACCESS procedure for allowing the server to permissions the access checks. This then prevents charlie or the superuser from gaining unauthorized access to files.
What if you have NFS clients that are not running Solaris 2.5 or higher, or are not running Solaris at all? In that situation you have two choices: live with the fact that some users will be denied access due to the minimal permissions behavior, or you can use the aclok option of the Solaris share command to allow maximal access. If the filesystem is shared with aclok, then if anyone has read access to the files, then everyone does. So, charlie would then be allowed to access file blockhead.
Another issue with NFS and ACLs is that the NFS protocol has no way to set or retrieve ACLs, i.e., there is no protocol support for the setfacl or getfacl command. Once again, the sideband protocol in Solaris 2.5 and higher comes to the rescue. The sideband protocol allows ACLs to be set and retrieved, so setfacl and getfacl work across NFS.
* * *
Tip
IBM's AIX and Compaq's Tru64 Unix have sideband ACL protocols for manipulating ACLs over NFS. Unfortunately, none of the three protocols are compatible with each other.
* * *
Are ACLs worth it?
With all the arcane details, caveats, and limitations we've seen, you as the system administrator may decide that ACLs are more pain than benefit. Nonetheless, ACLs are a feature that are available to users. Even if you don't want to actively support them, your users might attempt to use them, so it is a good idea to