Linux could write to read only files on FreeBSD NFS server
Peter Eriksson
pen at lysator.liu.se
Mon Mar 2 07:58:55 UTC 2020
I’ve 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 = 0x001 READ: allowed?
> .... .1.. = 0x004 MODIFY: allowed?
> .... 1... = 0x008 EXTEND: allowed?
> ..1. .... = 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 = 0x001 READ: allowed?
> .... .1.. = 0x004 MODIFY: allowed?
> .... 1... = 0x008 EXTEND: allowed?
> ..1. .... = 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 = 0x001 READ: allowed?
> .... .1.. = 0x004 MODIFY: allowed?
> .... 1... = 0x008 EXTEND: allowed?
> ..1. .... = 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 = 0x001 READ: *Access Denied*
> .... .0.. = 0x004 MODIFY: *Access Denied*
> .... 0... = 0x008 EXTEND: *Access Denied*
> ..0. .... = 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 at uoguelph.ca> wrote:
>
> Luoqi Chen wrote:
>> On Fri, Feb 28, 2020 at 3:13 AM Martin Simmons ><martin at lispworks.com<mailto:martin at lispworks.com>> wrote:
>>>>>>> On Thu, 27 Feb 2020 14:58:55 -0800, Luoqi Chen said:
>>>
>>> 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.
>>
>> Have you tried mounting it with nfsv3 recently? I can't repeat it with that
>> version (I don't run nfsv4 at all).
>>
>> 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:
>
> 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.
>
> 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.
>
> 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.
>
> Please let me know if you can test the patch and determine if the Linux NFSv4
> mount works with the patched FreeBSD server.
>
> rick
> <ownerover.patch>_______________________________________________
> freebsd-fs at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe at freebsd.org"
More information about the freebsd-fs
mailing list