Managing NFS and NIS, 2nd Edition - Mike Eisler [152]
Some NFS servers require the public option in the dfstab or the equivalent when exporting the filesystem in order for the server to accept the public filehandle. This is not the case for Solaris 8 NFS servers.
What about allowing NFS clients from the greater Internet to access NFS servers located behind your firewall? This a reasonable thing to do as well, provided you take some care. The NFS clients will be required to mount the servers' filesystems with the public option. You will then configure your firewall to allow TCP connections to originate from outside your Intranet to a specific list of NFS servers behind the firewall. Unless Network Address Translation gets in the way, you'll want to use the rw= or ro= options to export the filesystems only to specific NFS clients outside your Intranet. Of course, you should export with the nosuid option, too.
If you are going to use NFS firewalls to access critical data, be sure to read Section 12.5.3 later in this chapter.
Access control lists
Some NFS servers exist in an operating environment that supports Access Control Lists (ACLs). An ACL extends the basic set of read, write, execute permissions beyond those of file owner, group owner, and other. Let's say we have a set of users called linus, charlie, lucy, and sally, and these users comprise the group peanuts. Suppose lucy owns a file called blockhead, with group ownership assigned to peanuts. The permissions of this file are 0660 (in octal). Thus lucy can read and write to the file, as can all the members of her group. However, lucy decides she doesn't want charlie to read the file, but still wants to allow the other peanuts group members to access the file. What lucy can do is change the permissions to 0600, and then create an ACL that explicitly lists only linus and sally as being authorized to read and write the file, in addition to herself. Most Unix systems, including Solaris 2.5 and higher, support a draft standard of ACLs from the POSIX standards body. Under Solaris, lucy would prevent charlie from accessing her file by doing:
% chmod 0600 blockhead
% setfacl -m mask:rw-,user:linus:rw-,user:sally:rw- blockhead
To understand what setfacl did, let's read back the ACL for blockhead:
% getfacl blockhead
# file: blockhead
# owner: lucy
# group: peanuts
user::rw-
user:linus:rw- #effective:rw-
user:sally:rw- #effective:rw-
group::--- #effective:---
mask:rw-
other:---
The user: entries for sally and linus correspond to the rw permissions lucy requested. The user:: entry simply points out that the owner of the file, lucy has rw permissions. The group:: entry simply says that the group owner, peanuts, has no access. The mask: entry says what the maximum permissions are for any users (other than the file owner) and groups. If lucy had not included mask permissions in the setfacl command, then linus and sally would be denied access. The getfacl command would instead have shown:
% getfacl blockhead
# file: blockhead
# owner: lucy
# group: peanuts
user::rw-
user:linus:rw- #effective:---
user:sally:rw- #effective:---
group::--- #effective:---
mask:---
other:---
Note the difference from the two sets of getfacl output: the effective permissions granted to linus and sally.
Once you have the ACL on a file the way you want it, you can take the output of getfacl on one file and apply it to another file:
% touch patty
% getfacl blockhead | setfacl -f /dev/stdin patty
% getfacl patty
# file: patty
# owner: lucy
# group: peanuts
user::rw-
user:linus:rw- #effective:rw-
user:sally:rw- #effective:rw-
group::--- #effective:---
mask:rw-
other:---
It would be hard to disagree if you think this is a pretty arcane way to accomplish something that should be fairly simple. Nonetheless, ACLs can be leveraged to solve the "too many groups" problem