Re: NFSv4 on MacOS Monterey
- In reply to: Rick Macklem : "Re: NFSv4 on MacOS Monterey"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Thu, 02 Jun 2022 22:02:32 UTC
Rick Macklem <rmacklem@uoguelph.ca> wrote: > Adonis Peralta <donileo@gmail.com> wrote: [stuff snipped] > > OS: FreeBSD 13.1 [more stuff snipped] > > RESULTS > > > > What I see when I connect via finder is the following: > > > > 1. I am able to read/write to the shares since /etc/exports contains the -mapall line, yet inspecting a packet > trace shows me: > > > > === > > packet #1 > > --- > > client ip -> server ip Operations (count: 3): PUTFH, ACCESS, GETATTR > > Opcode: PUTFH (22) > > Opcode: ACCESS (3), [Check: RD LU MD XT DL XE] > > Opcode: GETATTR (9) > > > > packet #2 > > --- > > server ip -> client ip Operations (count: 3) > > Opcode: PUTFH (22) > > Opcode: ACCESS (3), [NOT Supported: XE], [Access Denied: MD XT DL], [Allowed: RD LU] > > Status: NFS4_OK (0) > > Supported types (of requested): 0x1f > > Access rights (of requested): 0x03 > > .... ...1 = 0x001 READ: allowed > > .... ..1. = 0x002 LOOKUP: allowed > > .... .0.. = 0x004 MODIFY: *Access Denied* > > .... 0... = 0x008 EXTEND: *Access Denied* > > ...0 .... = 0x010 DELETE: *Access Denied* > This is saying that the uid for "adonis" on the server does not have write access to the file. > > > Opcode: GETATTR (9) > > === > > > > Why is MD, XT, DL coming up as Access Denied if I can read/write to the > share? > Hmm, not sure. If you were to show all the reply fields for the Getattr, then > I could probably guess. > It might be Owner (is it "adonis@rambo.lan"). it could be ACLs. To check those, you should be able to > do whatever the Mac OSX equivalent to getfacl is. I suspect this might be caused by what is called OwnerOverride. It is a long standing tradition in NFS servers to allow the owner of a file to read/write the file despite what the file mode/ACL says. Why? Well, because unlike POSIX, NFS servers check permissions on every Read/Write instead of only upon the POSIX open(2). Without this, POSIX applications that first open(2) a file and then chmod(2) the file to a mode that does not allow further open(2)s of the same type, will break badly on NFS mounts. (NFS is not and will never be a POSIX compliant file system, due to the protocol.) This "cheat" of allowing the Owner access regardless, allows most of these POSIX programs to work over NFS. (And since the owner of the file can chmod/Setattr of mode at any time, it is not considered a security hole.) Now, for NFSv4, there is an Open (a form of Windows lock, not a POSIX open). It should fail for the case where it is not doing a Create and the permissions are not allowed. (This check was only added to the FreeBSD server recently, when it was identified as not doing the check, unlike Linux and Solaris. However, this check is in 13.1.) I can only conjecture that the NFSv4 Open specified Create in this case and, as such, the check was not applied. NFSv4 clients are expected to use the reply to Access to decide whether or not to permit the POSIX open(2). It appears that the Mac OSX client may not be doing this? rick > I have a feeling this is because UID/GID mapping is not happening correctly. I can see in the packet trace >that FreeBSD's `nfsd` is sending some credentials as `adonis@rambo.lan`, but MacOS's nfs client is sending uid 501 and gid 20 for my user in the RPC credentials. I don't see how `nfsd` will be able to map uid 501, gid 20 to the server's uid and gid and instead I was expecting `adonis@rambo.lan` to be sent for credentials from the client side. As noted above, with "-mapall" the uid/gids in the RPC header are completely ignored. > The link below tells me that this is an inherent issue with NFSv4? > https://dfusion.com.au/wiki/tiki-index.php?page=Why+NFSv4+UID+mapping+breaks+with+AUTH_UNIX > > 2. Extended attributes don't work at all. Here is the result: > === > $ cd /Volumes/media > $ touch test.txt > $ xattr -w com.example.color blue test.txt > > # Result: xattr: [Errno 1] Operation not permitted: 'test.txt' # > === Yep, as noted above, they aren't supported and will not work. FreeBSD uses the Linux style extended attribute model, not the resource fork/subfile one that Mac OSX and Solaris use. rick -- Adonis