From owner-freebsd-fs@freebsd.org Mon Mar 2 07:58:55 2020 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 184BF25D579 for ; Mon, 2 Mar 2020 07:58:55 +0000 (UTC) (envelope-from pen@lysator.liu.se) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48WCFj0NCcz4SrR for ; Mon, 2 Mar 2020 07:58:46 +0000 (UTC) (envelope-from pen@lysator.liu.se) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id E88FC4000B for ; Mon, 2 Mar 2020 08:58:36 +0100 (CET) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id D3D7C4001B; Mon, 2 Mar 2020 08:58:36 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,AWL autolearn=disabled version=3.4.2 X-Spam-Score: -1.0 Received: from [IPv6:2001:6b0:17:f002:d404:390a:cc85:358] (unknown [IPv6:2001:6b0:17:f002:d404:390a:cc85:358]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id 875AE4000B for ; Mon, 2 Mar 2020 08:58:35 +0100 (CET) From: Peter Eriksson Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Subject: Re: Linux could write to read only files on FreeBSD NFS server Date: Mon, 2 Mar 2020 08:58:35 +0100 References: <707243CD-C67E-4DAD-AC5A-68EC11CFFDFD@lysator.liu.se> <6EC06026-DA28-4CAC-8D56-5C7856D4625E@lysator.liu.se> <202002281113.01SBDlsl017697@higson.cam.lispworks.com> To: freebsd-fs In-Reply-To: Message-Id: <8247CFFC-C324-40BB-B0DD-B469A3B35851@lysator.liu.se> X-Mailer: Apple Mail (2.3608.60.0.2.5) X-Virus-Scanned: ClamAV using ClamSMTP X-Rspamd-Queue-Id: 48WCFj0NCcz4SrR X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=liu.se; spf=pass (mx1.freebsd.org: domain of pen@lysator.liu.se designates 2001:6b0:17:f0a0::3 as permitted sender) smtp.mailfrom=pen@lysator.liu.se X-Spamd-Result: default: False [-4.09 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.993,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+a:mail.lysator.liu.se]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-fs@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[4]; RCVD_TLS_LAST(0.00)[]; TO_DN_ALL(0.00)[]; DMARC_POLICY_ALLOW(-0.50)[liu.se,none]; RCVD_IN_DNSWL_NONE(0.00)[3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.a.0.f.7.1.0.0.0.b.6.0.1.0.0.2.list.dnswl.org : 127.0.11.0]; MV_CASE(0.50)[]; IP_SCORE(-1.80)[ip: (-7.10), ipnet: 2001:6b0::/32(-1.04), asn: 1653(-0.83), country: EU(-0.01)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1653, ipnet:2001:6b0::/32, country:EU]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2020 07:58:55 -0000 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: > 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: > 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: > 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: > 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: > 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: > 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: > 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: > 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: > 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 wrote: >=20 > Luoqi Chen wrote: >> On Fri, Feb 28, 2020 at 3:13 AM Martin Simmons = >> 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 > _______________________________________________ > 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"