Hello Gad,
Am 12.05.2021 um 13:00 schrieb Gad Miron <gadmiron@xxxxxxxxx>:
As to the root issue, He does not understand what you mean by root allowed
for the NFS share.
In Linux, what he's referring to is called "root_squash". NFS comes from the Unix world, so a bit of background knowledge might help.
The Unix administrative user (usually called "root") always has user-id 0.
Since NFSv3 and predecessors authenticate access via IP address (to whitelist hosts for access), and transparently pass the access rights and uid/gid of objects in the mounted tree, the nfs-client's local security system is responsible for enforcing access security.
It is crucial to understand that /etc/passwd is *also* just a way of resolving numeric user-ids to a name. (As administrator, one can effortless change the ownership of a file to a numeric id, *not listed in /etc/passwd*! This fact is not related to NFS.)
Example: On hosta, Alice creates a file on a local mountpoint, being exported via NFS. /etc/passwd associates her name with the userid 500. On hostb, the NFS export is mounted. Bob is logged in, and by chance has the user-id 500, because uids are just incremented with every defined user in /etc/passwd. Bob can now happily do anything with Alice's file as long as the access-rights (rwx, etc.) permit.
This was why Sun invented NIS back in the day, to have /etc/passwd in sync on all NFS clients. See
https://en.wikipedia.org/wiki/Network_Information_Service
Back to root_squash: If Alice logs in as root on her machine, and again creates a file with it's user-id 0, Bob (with his self-installed Linux, thus having root-access on that box), can again happily do anything with that root's file as long as the access-rights permit. This was seen as a gaping security issue. Thus, by convention, NFS-Servers map *accesses* from clients with user-id 0 to the userid of nobody (signed 16-Bit integer, -1 = 65534). If a remote "root" accesses any file on a NFS export, he in fact does this as user nobody. The same applies to group-id 0.
Sometimes, this root-access is desired and/or necessary, for netbooting clients from a read-only export, to have stressless access from VMware ESXi to NFS backing stores, etc. Thus, NFS-Servers can be instructed to *not* automatically map root (uid 0) to nobody (uid -1).
Hope this helps to clarify the issue at hand.
(On a side note, IBM i has a similar issue with Object Connect, the SAVRST* commands. If you run this as QSECOFR on your own — assumingly rogue — machine, it's possible to overwrite objects on remote machines: As long as the QSYS.LIB file's level-id match, and the rogue machine is allowed to establish an APPC session with the target. No apparent restrictions in /. And no, access is *not* dependent on user directory entries, seen with WRKDIRE.)
:wq! PoC
midrange.com
