ZFS & NFS

[Slawa Olhovchenkov]

On Fri, Mar 16, 2012 at 07:34:56PM +0100, Patrick M. Hausen wrote:

> Hello,
> 
> Am 16.03.2012 um 18:42 schrieb Slawa Olhovchenkov:
> > On Fri, Mar 16, 2012 at 06:32:43PM +0100, Patrick M. Hausen wrote:
> > 
> >> Hello,
> >> 
> >> Am 16.03.2012 um 18:20 schrieb Slawa Olhovchenkov:
> >>> I do NFSv3 export of ZFS.
> >>> root from remote host create files on ZFS witch uid 2^32-2:
> >>> 
> >>> # ls -l /usr/ports/packages32/
> >>> total 6
> >>> drwxr-xr-x  2 4294967294  wheel  5 Mar 17 00:57 All
> >>> drwxr-xr-x  2 4294967294  wheel  5 Mar 17 00:57 Latest
> >>> drwxr-xr-x  2 4294967294  wheel  3 Mar 17 00:52 archivers
> >>> drwxr-xr-x  2 4294967294  wheel  4 Mar 17 00:57 lang
> >> 
> >> 
> >> Yes? This is expected behaviour of NFS. If you don't want that, try
> >> 
> >> 	-maproot=root
> >> 
> >> either in sharenfs option to zfs or /etc/exports, whichever it is you are using.
> > 
> > hmm...
> > nobody:*:65534:65534:Unprivileged user:/nonexistent:/usr/sbin/nologin
> > 
> > 65534 != 4294967294 (2^16-2 != 2^32-2)
> > 
> > Also, I am think ZFS+NFS will be wrong for UID>2^15.
> 
> I admit I overlooked that one (16 vs 32 bits). But if I'm not mistaken, NFS does not care
> a bit about the name of the user "nobody" or the UID in /etc/passwd or what-have-you.
> It simply sets the UID of remote root (UID 0) to the value -1.

https://blogs.oracle.com/taylor22/entry/nfs_root_access_on_sun

===
In a default configuration, a Solaris NFS server maps "root" access to
"nobody". 
===

http://pubs.opengroup.org/onlinepubs/9629799/chap12.htm#tagcjh_13_03_03

===
In some operating systems, a particular user (on UNIX systems, the
user ID 0) has access to all files, no matter what permission and
ownership they have. This super-user permission might not be allowed
on the server, since anyone who can become super-user on their client
could gain access to all remote files. A UNIX server by default maps
user ID 0 to a distinguished value (UID_NOBODY), as well as mapping
the groups list, before doing its access checking. A server
implementation may provide a mechanism to change this mapping. This
works except for NFS Version 3 protocol root file systems (required
for diskless NFS Version 3 protocol client support), where super-user
access cannot be avoided. Export options are used, on the server, to
restrict the set of clients allowed super-user access. 
===

/usr/include/sys/_types.h:typedef       __uint32_t      __uid_t;

> And 4294967294 happens to be -1 in 32 bits signed. So - possibly this is built into
> ZFS this way. I would at least give the sharenfs="..." options a try ...

4294967294 happens to be -2 in 32 bits signed.
And I see type of UID (uid_t) is unsigned.