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