Hello Gad,
Am 05.04.2025 um 10:44 schrieb Gad Miron <gadmiron@xxxxxxxxx>:
Latest on chapter nnn of NFS MOUNT blues series:
The Win domain admin (after consulting with CHATGPT) asked for the MOUNT to be made by a user having UID = 1000 and GID=1000 (for test purposes)
So I created a dummy usrprf with UID = 1000 and GID=1000 and used it to do the MOUNT.
Same result - files are created locked.
I'm not surprised.
NFS in general has no notion of users, or even authentication. Some crude way of authentication is done by allowing or denying access to the NFS server as a whole based on IP address: Which machine(s) is/are allowed to connect. Instead, authentication is shifted to the client machine's username/password mechanisms.
The use case back then, decades ago, was a central (Sun Microsystems) server with a lot of disk space where users had their home directories located. And there were "computing nodes" (not called like that back then), sometimes even without any local disk, booted over the network. User can sit on the console on any of those nodes and use the local RAM and CPU resources, while accessing their files on remote disk space. He only needed to authenticate once: At login time. And the admin only needed to mount the superordinate directory once (and automatically) at system boot.
Who is actually doing the mount is irrelevant. In fact, on Linux/Unix, only root is allowed to mount filesystems.
This is contrary to user based file server access, where each user is responsible for authenticating against a file server separately. (/QNTC is doing this transparently behind the user's back when they access /QNTC, so it feels like NFS.)
Authorization for NFS presented files is done solely based on user-IDs, group-IDs, and associated UNIX permissions.
NFSv4 has optional Kerberos authentication, but I never had a compelling use case, so I never cared to learn the gory details.
On Unix/Linux, mapping from/to IDs is done through /etc/passwd and /etc/group text files. You're perfectly allowed to do a chown/chgrp for a file to a numeric user/group, one that is not listed in said files. This can also happen accidentally when a user is deleted on Linux/Unix, but still has objects "assigned". From the file system's view, there is no user, only IDs. 😊 And ls -l translates "on the fly"…
If you create a user profile with the UID 1000 on the server and chown some files to it, the NFS client only sees UID 1000 for those files. You need to take care that the NFS client itself has a local user with UID 1000. Fun fact: It doesn't need to have the same name as on the server. A great way to spread confusion.
However, if a user with the UID 1000 on the NFS client accesses those files, the permission bits for the user come into play (most often rwx for directories, and rw- for files). That's the sole authorization mechanism NFS up to version 3 provides.
To counter the problem with different UIDs/GIDs using different user names, a so called ID Mapper service has been supplemented. That transparently adapts the client's presentation of the server's files to map on user and group names. If the server has a user foo with ID 1000, and the client has the same user foo with ID 1001, the client side ID Mapper changes the files owned by foo on the server to ID 1001 instead of 1000.
Hope this provides some historical context about NFS and the way it works. Although this doesn't solve your locking issue. As far as I know, Microsoft is phasing out NFS support in Windows, so this might be the opportunity to switch to QNTC, as advised earlier.
Some more background information…
Another invention by Sun Microsystems is NIS, a directory server which predates LDAP. It essentially provides remote access to a server's /etc/passwd and /etc/group (amongst others) to have a common user base. Decades ago I used that myself for a while. Very robust, very neatly integrated.
What about root? Anyone can nowadays bring in a Raspberry Pi, log in as root and mount an NFS share from a server which allows the Raspi's IP address. And in turn fiddle with things belonging to root. Big security hole?
By default, NFS implicitly rewrites file system objects having UID/GID 0 (root) to that of nobody/nogroup. This is called root squashing. A quick test shows that root squashing isn't taking place. Maybe because of the ID Mapper?
Also, I don't know how bending IDs should "enhance" security. Someone who is able to switch user to root on a roguue client is also able to switch user to nobody. Maybe I'm overlooking something. It's been some years. 🤷♂️
Nowadays, I'm using NFS solely providing backing storage purposes for a number of ESXi hosts over 10 GbE. Permissions and users aren't involved on that layer. Everything belongs to root and is read/writable by root.
:wq! PoC
midrange.com
