What does the NO_ALL_SQUASH option do in NFS exports?

Question

From the exports(5) man page, in the "User ID Mapping" section, it says:

User ID Mapping

...

Very often, it is not desirable that the root user on a client machine is also treated as root when accessing files on the NFS server. To this end, uid 0 is normally mapped to a different id: the so-called anonymous or nobody uid. This mode of operation (called `root squashing') is the default, and can be turned off with no_root_squash.

...

Here's the complete list of mapping options:

root_squash

Map requests from uid/gid 0 to the anonymous uid/gid. Note that this does not apply to any other uids or gids that might be equally sensitive, such as user bin or group staff.

no_root_squash

Turn off root squashing. This option is mainly useful for diskless clients.

all_squash

Map all uids and gids to the anonymous user. Useful for NFS-exported public FTP directories, news spool directories, etc. The opposite option is no_all_squash, which is the default setting.

...

I summarized the UID mapping options in the following table (assumed 1000 to be the UID of a non-privileged user, and 65534 to be the anonymous UID):

Option	Client UID	Server UID
root_squash	0	65534
root_squash	1000	1000
no_root_squash	0	0
no_root_squash	1000	1000
all_squash	0	65534
all_squash	1000	65534
no_all_squash	0	0 (unsure)
no_all_squash	1000	65534 (unsure)

Question

1. Is my summary for the no_all_squash option correct? If yes, when will it be useful?
2. Which option is the default? The paragraph above says root_squash, while no_all_squash claims itself default in the options explanation.

Thank you in advance!

Answer 1

After setting up a pair of NFS server and client in a virtual environment, I found the following result:

Option	Client UID	Server UID
root_squash	0	65534
root_squash	1000	1000
no_root_squash	0	0
no_root_squash	1000	1000
all_squash	0	65534
all_squash	1000	65534
no_all_squash	0	65534
no_all_squash	1000	1000

In other words, the no_all_squash option appears to behave the same as the root_squash option. This answers Question 1 and explains Question 2 at the same time.

Answer 2

Root squash/no root squash has no bearing on the client ID you're going to see doing the read/write, only on whether or not root is allowed to butt in and make changes regardless of whether or not it is included in the permission set. Root squash will prevent local root from changing the ownership of files.

Generally root squash is left off, unless there is a pressing security reason to bind files to specific users. Root is assumed to be protected, and users are assumed to not have root access. If the data on the share needs to be maintained at the share level, then root squash can be desirable.

Answer 3

The usual approach is to allow root mapping between machines. Furthermore, the old NFS legacy approach used NIS to sync user id's in a NIS domain for this exact purpose: otherwise same users with different ids would be confused for each other.

Squashing is used in some rare cases when, on one hand, you want to allow NFS access to some clients that aren't yours, and on the other hand, you don't want them to have full access if they are using id 0. Usually the NFS is configured across single organization network, where all of the machined are administered by one team of engineers.

As about all/none squashing/no-squashing - the end was simple: when you want to apply some complicated ACLs for your filesystem tree, you have to use the NFSv4 which handles the ACL properly, because NFSv<=3 merely does not, with or without squashing (the latter only makes the NFSv<=3 access model cumbersome, but not complete). Last part was the main reason NFSv4 appeared after all.