Highlighted
Absent Member.
Absent Member.
2139 views

NFS exports and the mandatory no_root_squash

We are running a SUSE11/OES11 cluster serving NSS volumes as NCP, NFS and AFP. Is the only feasible workaround for the NFS no_root_squash requirement to firewall the mountd port?

If so will having a list of 1,000+ IP numbers in the allow list for mountd have a significant impact on the cluster nodes? Unfortunately on our University class B IPv4 site the allocated IP addresses are scattered and the subset of PCs controlled by technicians (and therefore 'trusted') are not contiguous and neatly arranged.
Labels (1)
0 Likes
3 Replies
Absent Member.
Absent Member.

Re: NFS exports and the mandatory no_root_squash

There is another workaround to the "no_root_squash" requirement. The below is taken from TID: Support | OES: Compatibility issues between NSS and NFS

-------------
2. no_root_squash: Officially, this is mandatory, so care should be taken to limit what hosts can mount the export (as the root user of the NFS client host will be able to act as the root user on the NSS exported path).

However, due to potential security concerns with allowing root access, some administrators chose to set this up in another way. This alternative way is thus far considered experimental, and not thoroughly tested: It seems that the key requirement here is that the user who is requesting the mount (typically root) have at least Filescan rights to the NSS volume. If root is "squashed" he is treated like "nobody." Typically, "nobody" does not have access, neither through its own merits nor by being associated with any LUM-enabled user in eDir. However, an eDir user can be created and LUM-enabled, given Filescan right to the NSS volume(s), and then the UID assigned to that user can be used as the "anonuid" for that particular export. So, for example, if the user in question was given UID 1011, then instead of "no_root_squash" the combination of "root_squash,anonuid=1011" could be used.

In that case, be sure to remember that even after mount, "squashed root user" will be treated as having whatever rights the anonuid user has been given. Also remember that if you use the "all_squash" parameter as well, all NFS client users (not just eDir users and not just root) will be treated as the anonuid user, and will be able to access the NSS volume.
-------------------

On the other subject: I do not know the potential impact of 1000+ IP numbers in an allow list for mountd.

Darcy
0 Likes
Highlighted
Absent Member.
Absent Member.

Re: NFS exports and the mandatory no_root_squash

Thank you. I will try and implement this and see how it goes.
0 Likes
Highlighted
Absent Member.
Absent Member.

Re: NFS exports and the mandatory no_root_squash

Darcy,

This appears to be working. Root users have the ability to list files/folders on an NFS export but no ability to read file contents or write to anything.

Thanks for your help.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.