Date: Mon, 2 Mar 2020 22:48:06 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: Peter Eriksson <pen@lysator.liu.se>, freebsd-fs <freebsd-fs@freebsd.org> Subject: Re: Linux could write to read only files on FreeBSD NFS server Message-ID: <YTBPR01MB33743D2BD467E943C9781AADDDE70@YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <8247CFFC-C324-40BB-B0DD-B469A3B35851@lysator.liu.se> References: <CAHJqQjuEVpL4xV1dAf6scFqFfMNm1gY3jOaO64ZQJTCQi_qzcQ@mail.gmail.com> <707243CD-C67E-4DAD-AC5A-68EC11CFFDFD@lysator.liu.se> <6EC06026-DA28-4CAC-8D56-5C7856D4625E@lysator.liu.se> <YTBPR01MB3374713F573B548791A22F98DDEB0@YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM> <CAHJqQjsP-w9LAS4AV64Pu9Jmv0kVFodKdT_jLUcyop3sNVh_EA@mail.gmail.com> <202002281113.01SBDlsl017697@higson.cam.lispworks.com> <CAHJqQjt4M_j5=85wcb2hcMC7nepV0ktAtOxbinvj%2BVv2cFWG5g@mail.gmail.com> <YTBPR01MB337401285CAA695E1D7AA5BADDE70@YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM>, <8247CFFC-C324-40BB-B0DD-B469A3B35851@lysator.liu.se>
next in thread | previous in thread | raw e-mail | index | archive | help
Peter Eriksson wrote:=0A= >I=92ve tested a Linux client vs FreeBSD, Linux & Solaris (OmniOS) NFS serv= ers and it seems both >Linux & Solaris does give a NFS4ERR_ACCESS (13) erro= r on the OPEN NFS procedure. >Tcpdump outputs for reference:=0A= Interesting. When I use the patch I posted a very old test suite I still us= e (from=0A= connectathon) breaks because it creates files with mode 444 and then tries = to write them.=0A= (This test suite was used for a long time for NFSv3. Maybe they patched it = for NFSv4=0A= testing at some point or just decided the test suite was broken for NFSv4?= )=0A= =0A= There is also the case where delegations are enabled and the Open doesn't e= ven happen.=0A= =0A= Anyhow, if others test the patch and like it, I can commit it controlled vi= a a sysctl.=0A= I'd just have to decide whether it should be enabled by default or not.=0A= =0A= rick=0A= =0A= Linux Client, Linux Server:=0A= =0A= > Frame 14: 394 bytes on wire (3152 bits), 394 bytes captured (3152 bits)= =0A= > Ethernet II, Src: Cisco_5f:47:00 (44:d3:ca:5f:47:00), Dst: HewlettP_0a:d4= :74 (98:4b:e1:0a:d4:74)=0A= > Internet Protocol Version 4, Src: 10.245.33.50, Dst: 130.236.146.121=0A= > Transmission Control Protocol, Src Port: 1007, Dst Port: 2049, Seq: 1773,= Ack: 1597, Len: 328=0A= > Remote Procedure Call, Type:Call XID:0xa1be47fe=0A= > Network File System, Ops(5): SEQUENCE, PUTFH, OPEN, ACCESS, GETATTR=0A= > [Program Version: 4]=0A= > [V4 Procedure: COMPOUND (1)]=0A= > Tag: <EMPTY>=0A= > minorversion: 1=0A= > Operations (count: 5): SEQUENCE, PUTFH, OPEN, ACCESS, GETATTR=0A= > Opcode: SEQUENCE (53)=0A= > sessionid: 526f545ecc2d22bc0100000000000000=0A= > seqid: 0x00000237=0A= > slot id: 0=0A= > high slot id: 0=0A= > cache this?: Yes=0A= > Opcode: PUTFH (22)=0A= > FileHandle=0A= > Opcode: OPEN (18)=0A= > seqid: 0x00000000=0A= > share_access: OPEN4_SHARE_ACCESS_READ (1)=0A= > share_deny: OPEN4_SHARE_DENY_NONE (0)=0A= > clientid: 0x526f545ecc2d22bc=0A= > owner: <DATA>=0A= > Open Type: OPEN4_NOCREATE (0)=0A= > Claim Type: CLAIM_FH (4)=0A= > Opcode: ACCESS (3), [Check: RD MD XT XE]=0A= > Check access: 0x2d=0A= > .... ...1 =3D 0x001 READ: allowed?=0A= > .... .1.. =3D 0x004 MODIFY: allowed?=0A= > .... 1... =3D 0x008 EXTEND: allowed?=0A= > ..1. .... =3D 0x020 EXECUTE: allowed?=0A= > Opcode: GETATTR (9)=0A= > Attr mask[0]: 0x0010011a (Type, Change, Size, FSID, FileId)= =0A= > Attr mask[1]: 0x00b0a23a (Mode, NumLinks, Owner, Owner_Group,= RawDev, Space_Used, Time_Access, Time_Metadata, Time_Modify, Mounted_on_Fi= leId)=0A= > [Main Opcode: OPEN (18)]=0A= =0A= > Frame 15: 166 bytes on wire (1328 bits), 166 bytes captured (1328 bits)= =0A= > Ethernet II, Src: HewlettP_0a:d4:74 (98:4b:e1:0a:d4:74), Dst: Cisco_5f:47= :00 (44:d3:ca:5f:47:00)=0A= > Internet Protocol Version 4, Src: 130.236.146.121, Dst: 10.245.33.50=0A= > Transmission Control Protocol, Src Port: 2049, Dst Port: 1007, Seq: 1597,= Ack: 2101, Len: 100=0A= > Remote Procedure Call, Type:Reply XID:0xa1be47fe=0A= > Network File System, Ops(3): SEQUENCE PUTFH OPEN(NFS4ERR_ACCESS)=0A= > [Program Version: 4]=0A= > [V4 Procedure: COMPOUND (1)]=0A= > Status: NFS4ERR_ACCESS (13)=0A= > Tag: <EMPTY>=0A= > Operations (count: 3)=0A= > Opcode: SEQUENCE (53)=0A= > Status: NFS4_OK (0)=0A= > sessionid: 526f545ecc2d22bc0100000000000000=0A= > seqid: 0x00000237=0A= > slot id: 0=0A= > high slot id: 9=0A= > target high slot id: 9=0A= > status flags: 0x00000000=0A= > Opcode: PUTFH (22)=0A= > Status: NFS4_OK (0)=0A= > Opcode: OPEN (18)=0A= > Status: NFS4ERR_ACCESS (13)=0A= > [Main Opcode: OPEN (18)]=0A= =0A= =0A= =0A= =0A= Linux Client, Solaris(OmniOS) Server:=0A= =0A= > Frame 45: 334 bytes on wire (2672 bits), 334 bytes captured (2672 bits)= =0A= > Ethernet II, Src: Dell_e5:42:64 (d4:be:d9:e5:42:64), Dst: Elitegro_63:aa:= 39 (c0:3f:d5:63:aa:39)=0A= > Internet Protocol Version 6, Src: 2001:6b0:17:f002:d6be:d9ff:fee5:4264, D= st: 2001:6b0:17:f002:c23f:d5ff:fe63:aa39=0A= > Transmission Control Protocol, Src Port: 989, Dst Port: 2049, Seq: 1877, = Ack: 1877, Len: 248=0A= > Remote Procedure Call, Type:Call XID:0x475ab0a2=0A= > Network File System, Ops(5): PUTFH, OPEN, GETFH, ACCESS, GETATTR=0A= > [Program Version: 4]=0A= > [V4 Procedure: COMPOUND (1)]=0A= > Tag: <EMPTY>=0A= > minorversion: 0=0A= > Operations (count: 5): PUTFH, OPEN, GETFH, ACCESS, GETATTR=0A= > Opcode: PUTFH (22)=0A= > FileHandle=0A= > Opcode: OPEN (18)=0A= > seqid: 0x00000003=0A= > share_access: OPEN4_SHARE_ACCESS_WRITE (2)=0A= > share_deny: OPEN4_SHARE_DENY_NONE (0)=0A= > clientid: 0x000000655e5980e1=0A= > owner: <DATA>=0A= > Open Type: OPEN4_NOCREATE (0)=0A= > Claim Type: CLAIM_NULL (0)=0A= > Opcode: GETFH (10)=0A= > Opcode: ACCESS (3), [Check: RD MD XT XE]=0A= > Check access: 0x2d=0A= > .... ...1 =3D 0x001 READ: allowed?=0A= > .... .1.. =3D 0x004 MODIFY: allowed?=0A= > .... 1... =3D 0x008 EXTEND: allowed?=0A= > ..1. .... =3D 0x020 EXECUTE: allowed?=0A= > Opcode: GETATTR (9)=0A= > Attr mask[0]: 0x0010011a (Type, Change, Size, FSID, FileId)= =0A= > Attr mask[1]: 0x00b0a23a (Mode, NumLinks, Owner, Owner_Group,= RawDev, Space_Used, Time_Access, Time_Metadata, Time_Modify, Mounted_on_Fi= leId)=0A= > [Main Opcode: OPEN (18)]=0A= =0A= > Frame 46: 170 bytes on wire (1360 bits), 170 bytes captured (1360 bits)= =0A= > Ethernet II, Src: Elitegro_63:aa:39 (c0:3f:d5:63:aa:39), Dst: Dell_e5:42:= 64 (d4:be:d9:e5:42:64)=0A= > Internet Protocol Version 6, Src: 2001:6b0:17:f002:c23f:d5ff:fe63:aa39, D= st: 2001:6b0:17:f002:d6be:d9ff:fee5:4264=0A= > Transmission Control Protocol, Src Port: 2049, Dst Port: 989, Seq: 1877, = Ack: 2125, Len: 84=0A= > Remote Procedure Call, Type:Reply XID:0x475ab0a2=0A= > Network File System, Ops(2): PUTFH OPEN(NFS4ERR_ACCESS)=0A= > [Program Version: 4]=0A= > [V4 Procedure: COMPOUND (1)]=0A= > Status: NFS4ERR_ACCESS (13)=0A= > Tag: <EMPTY>=0A= > Operations (count: 2)=0A= > Opcode: PUTFH (22)=0A= > Status: NFS4_OK (0)=0A= > Opcode: OPEN (18)=0A= > Status: NFS4ERR_ACCESS (13)=0A= > [Main Opcode: OPEN (18)]=0A= =0A= =0A= =0A= =0A= Linux Client, FreeBSD Server:=0A= =0A= > Frame 41: 362 bytes on wire (2896 bits), 362 bytes captured (2896 bits)= =0A= > Ethernet II, Src: Dell_e5:42:64 (d4:be:d9:e5:42:64), Dst: Cisco_6b:86:bf = (64:9e:f3:6b:86:bf)=0A= > Internet Protocol Version 6, Src: 2001:6b0:17:f002:d6be:d9ff:fee5:4264, D= st: 2001:6b0:17:2400::8:40=0A= > Transmission Control Protocol, Src Port: 802, Dst Port: 2049, Seq: 1913, = Ack: 2437, Len: 276=0A= > Remote Procedure Call, Type:Call XID:0xf62930df=0A= > Network File System, Ops(5): SEQUENCE, PUTFH, OPEN, ACCESS, GETATTR=0A= > [Program Version: 4]=0A= > [V4 Procedure: COMPOUND (1)]=0A= > Tag: <EMPTY>=0A= > minorversion: 1=0A= > Operations (count: 5): SEQUENCE, PUTFH, OPEN, ACCESS, GETATTR=0A= > Opcode: SEQUENCE (53)=0A= > sessionid: 183000000000000059a4585e18300000=0A= > seqid: 0x00000022=0A= > slot id: 0=0A= > high slot id: 0=0A= > cache this?: Yes=0A= > Opcode: PUTFH (22)=0A= > FileHandle=0A= > Opcode: OPEN (18)=0A= > seqid: 0x00000000=0A= > share_access: OPEN4_SHARE_ACCESS_WRITE (2)=0A= > share_deny: OPEN4_SHARE_DENY_NONE (0)=0A= > clientid: 0x59a4585e18300000=0A= > owner: <DATA>=0A= > Open Type: OPEN4_NOCREATE (0)=0A= > Claim Type: CLAIM_FH (4)=0A= > Opcode: ACCESS (3), [Check: RD MD XT XE]=0A= > Check access: 0x2d=0A= > .... ...1 =3D 0x001 READ: allowed?=0A= > .... .1.. =3D 0x004 MODIFY: allowed?=0A= > .... 1... =3D 0x008 EXTEND: allowed?=0A= > ..1. .... =3D 0x020 EXECUTE: allowed?=0A= > Opcode: GETATTR (9)=0A= > Attr mask[0]: 0x0010011a (Type, Change, Size, FSID, FileId)= =0A= > Attr mask[1]: 0x00b0a23a (Mode, NumLinks, Owner, Owner_Group,= RawDev, Space_Used, Time_Access, Time_Metadata, Time_Modify, Mounted_on_Fi= leId)=0A= > [Main Opcode: OPEN (18)]=0A= =0A= > Frame 42: 462 bytes on wire (3696 bits), 462 bytes captured (3696 bits)= =0A= > Ethernet II, Src: Cisco_6b:86:bf (64:9e:f3:6b:86:bf), Dst: Dell_e5:42:64 = (d4:be:d9:e5:42:64)=0A= > Internet Protocol Version 6, Src: 2001:6b0:17:2400::8:40, Dst: 2001:6b0:1= 7:f002:d6be:d9ff:fee5:4264=0A= > Transmission Control Protocol, Src Port: 2049, Dst Port: 802, Seq: 2437, = Ack: 2189, Len: 376=0A= > Remote Procedure Call, Type:Reply XID:0xf62930df=0A= > Network File System, Ops(5): SEQUENCE PUTFH OPEN ACCESS GETATTR=0A= > [Program Version: 4]=0A= > [V4 Procedure: COMPOUND (1)]=0A= > Status: NFS4_OK (0)=0A= > Tag: <EMPTY>=0A= > Operations (count: 5)=0A= > Opcode: SEQUENCE (53)=0A= > Status: NFS4_OK (0)=0A= > sessionid: 183000000000000059a4585e18300000=0A= > seqid: 0x00000022=0A= > slot id: 0=0A= > high slot id: 63=0A= > target high slot id: 63=0A= > status flags: 0x00000000=0A= > Opcode: PUTFH (22)=0A= > Status: NFS4_OK (0)=0A= > Opcode: OPEN (18)=0A= > Status: NFS4_OK (0)=0A= > StateID=0A= > change_info=0A= > result flags: 0x00000004, locktype posix=0A= > Delegation Type: OPEN_DELEGATE_NONE (0)=0A= > Opcode: ACCESS (3), [Access Denied: RD MD XT XE]=0A= > Status: NFS4_OK (0)=0A= > Supported types (of requested): 0x2d=0A= > Access rights (of requested): 0x00=0A= > .... ...0 =3D 0x001 READ: *Access Denied*=0A= > .... .0.. =3D 0x004 MODIFY: *Access Denied*=0A= > .... 0... =3D 0x008 EXTEND: *Access Denied*=0A= > ..0. .... =3D 0x020 EXECUTE: *Access Denied*=0A= > Opcode: GETATTR (9)=0A= > Status: NFS4_OK (0)=0A= > Attr mask[0]: 0x0010011a (Type, Change, Size, FSID, FileId)= =0A= > Attr mask[1]: 0x00b0a23a (Mode, NumLinks, Owner, Owner_Group,= RawDev, Space_Used, Time_Access, Time_Metadata, Time_Modify, Mounted_on_Fi= leId)=0A= > [Main Opcode: OPEN (18)]=0A= =0A= =0A= =0A= - Peter=0A= =0A= =0A= > On 2 Mar 2020, at 01:19, Rick Macklem <rmacklem@uoguelph.ca> wrote:=0A= >=0A= > Luoqi Chen wrote:=0A= >> On Fri, Feb 28, 2020 at 3:13 AM Martin Simmons ><martin@lispworks.com<ma= ilto:martin@lispworks.com>> wrote:=0A= >>>>>>> On Thu, 27 Feb 2020 14:58:55 -0800, Luoqi Chen said:=0A= >>>=0A= >>> One more piece of information that might help: this behavior started=0A= >>> somewhere between centos 5 and 6, kernel 2.6.18 and 2.6.32, i.e., the s= ame=0A= >>> script would fail on 2.6.18. Timing wise I believe it coincided with th= e=0A= >>> introduction of nfsv4.=0A= >>=0A= >> Have you tried mounting it with nfsv3 recently? I can't repeat it with = that=0A= >> version (I don't run nfsv4 at all).=0A= >>=0A= >> Looks like I'm getting senile... The script works correctly with nfsv3 m= ounts. This is=0A= >> a nfsv4 specific problem.=0A= > Ok, I've re-read the Open section of the NFSv4 RFCs. They all have simila= r wording.=0A= > I can see how it can be interpreted multiple ways. Here's the RFC 5661 sn= ippet:=0A= >=0A= > Based on the share_access value (OPEN4_SHARE_ACCESS_READ,=0A= > OPEN4_SHARE_ACCESS_WRITE, or OPEN4_SHARE_ACCESS_BOTH), the client=0A= > should check that the requester has the proper access rights to=0A= > perform the specified operation. This would generally be the results= =0A= > of applying the ACL access rules to the file for the current=0A= > requester. However, just as with the ACCESS operation, the client=0A= > should not attempt to second-guess the server's decisions, as access=0A= > rights may change and may be subject to server administrative=0A= > controls outside the ACL framework. If the requester's READ or WRITE= =0A= > operation is not authorized (depending on the share_access value),=0A= > the server MUST return NFS4ERR_ACCESS.=0A= >=0A= > Now, I had interpreted the last sentence meaning "apply the same check=0A= > as Read/Write does". Since the owner of the file is always allowed to Rea= d/Write=0A= > (as explained in a previous post), that is what the FreeBSD NFSv4 server = does.=0A= > However, I can see that it could be interpreted as "return NFS4ERR_ACCESS= if=0A= > the file modes/ACL would result in an EACCES error".=0A= > --> As such, although it could result in an inconsistency between NFSv3 a= nd=0A= > NFSv4, I could see the Linux client depending on that instead of us= ing=0A= > the replied information for the Access operation to decide if a POS= IX=0A= > Open should be allowed.=0A= >=0A= > Anyhow, I've attached a trivial patch that changes the NFSv4 Open semanti= cs=0A= > to conform to what the mode/ACL indicates.=0A= > I am not sure that this patch should be applicable to head, but if it mak= es the=0A= > Linux client happy, I can see it being optionally enabled via a sysctl.= =0A= >=0A= > Please let me know if you can test the patch and determine if the Linux N= FSv4=0A= > mount works with the patched FreeBSD server.=0A= >=0A= > rick=0A= > <ownerover.patch>_______________________________________________=0A= > freebsd-fs@freebsd.org mailing list=0A= > https://lists.freebsd.org/mailman/listinfo/freebsd-fs=0A= > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"=0A= =0A= _______________________________________________=0A= freebsd-fs@freebsd.org mailing list=0A= https://lists.freebsd.org/mailman/listinfo/freebsd-fs=0A= To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"=0A=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YTBPR01MB33743D2BD467E943C9781AADDDE70>