NFS broken?

[Foon]

Howdy,

I'm seeing some odd behaviour from the NFS server in FreeNAS 8.0.4 (also in 8.0.2, which I just upgraded from in an attempt to fix the issue). Essentially I'm sharing out (via NFS) different parts of a RAID-6 volume with different permissions. My /etc/exports is as follows:

/mnt/storage/NFS/hutch -alldirs -maproot=root: -network 192.168.0.0/24
/mnt/storage/NFS/debian64root -alldirs -maproot=root: -network 192.168.0.0/24
/mnt/storage -alldirs -mapall=guest:storage -network 192.168.0.0/16

This is what I intended; it matches what I set in the web GUI. However, showmount -e (either locally or remote) reports:

Exports list on localhost:
/mnt/storage/NFS/hutch 192.168.0.0 192.168.0.0

Despite the showmount output I can actually mount /mnt/storage remotely over NFS, but the mapall gets ignored and instead the remote UID/GID are set on the FreeNAS box. What's going on here? Why does the actual list of exports not correspond to what's in /etc/exports (which is what I wanted) or what I can actually mount?

 

[peterh]

you shoild leave out -alldirs

 

[Foon]

Hmm, better but still broken. /etc/exports now reads:

/mnt/storage/NFS/hutch -maproot=root: -network 192.168.0.0/24
/mnt/storage/NFS/debian64root -maproot=root: -network 192.168.0.0/24
/mnt/storage -mapall=guest:storage -network 192.168.0.0/16

showmount -e shows:

/mnt/storage/NFS/hutch 192.168.0.0
/mnt/storage 192.168.0.0

and the mapall for /mnt/storage is still not being followed. Any other ideas?

 

[peterh]

I guess that /mnt/storage is the pool iteself. It's a bad idea to do anything with the pool itself.
at least move down to /mnt/storage/NFS

the other thing to map anything is generally bad, it does not give the security you think.
Do you really need to map anything to root ( if yes, limit to a host)
To mapall in order to get some "anonymus access" seems stupid, you lose all tracability Make the users coodiante their UID.

 

[Foon]

Can you cite some sources for any of this? I'd like to read more, since I assumed that once a pool is mounted into the filesystem it's not anything special and there shouldn't be a problem layering anything else on top. I can move things around if needed, I'd just like to understand why. I also wasn't aware that mapping UID/GID was at all a security risk - again, if you can cite a reference for this I'd like to learn more about what you mean there.

The mapall is a convenience issue - I have multiple clients accessing the same folder via SMB and NFS shares, so synchronizing would be a pain (we have no NIS). Traceability is a non-issue in my environment; it's more important that the fileserver "just works" for all clients, hence the anonymizing mapall. I can work around this.

As for the maproot - yes it is needed. The NFS/ folders are shared out to allow netbooting of diskless clients, which complain if they can't do things like mknod. Long-term the plan is to change these systems to read-only root filesystems but they're living with maproot for now.

Regardless of the security of mapall / maproot though, it concerns me that /etc/exports does not correspond to what the NFS server is actually doing. Are there any known issues with either exporting nested folders with different permissions, or mapall/maproot being ignored? I see nothing in the bug trackers and don't understand why nfsd would behave like this.

 

[peterh]

Using "the pool" itself prevents from setting qota ( or any other property that "zfs" has. And it's unneded as
you only have to "move down" one level.

mapping UID as in your example gives an ambuguity as you wants two different mappings ( to root and to guest)
for the same hierarcy. NFS "exports" is a "mount-time" thing not a "per access thing as in cifs. And it's not a freebsd
limitation,( try this with solaris if you like, or read the solaris spec's about nfs3 )

Having security depend on this is easily spoofed, it does not elevate security.