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