Linux could write to read only files on FreeBSD NFS server

Rick Macklem rmacklem at uoguelph.ca
Mon Mar 2 22:48:10 UTC 2020


Peter Eriksson wrote:
>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:
Interesting. When I use the patch I posted a very old test suite I still use (from
connectathon) breaks because it creates files with mode 444 and then tries to write them.
(This test suite was used for a long time for NFSv3. Maybe they patched it for NFSv4
 testing at some point or just decided the test suite was broken for NFSv4?)

There is also the case where delegations are enabled and the Open doesn't even happen.

Anyhow, if others test the patch and like it, I can commit it controlled via a sysctl.
I'd just have to decide whether it should be enabled by default or not.

rick

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"

_______________________________________________
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