Linux could write to read only files on FreeBSD NFS server

[Rick Macklem]

Peter Eriksson wrote:
>I see that this was a bit unclear, writing to the protected file was via NFS from a Linux (CentOS >7) client. I verified the ACLs and the file content both via NFSv4 and locally on the FreeBSD >server.
>
>Writing from an OmniOS (OpenSolaris) client fails. As does a local write. As it should...
>
>Also, it’s not related to ACLs (atleast not directly). Using “chmod” gives the same effect:
>
>> $ rm -f x
>> $ touch x
>> $ chmod 000 x
>> $ ls -l x
>> ---------- 1 peter86 employee-liu.se 0 27 feb 22.46 x
>> $ echo foo >x
>> $ cat x
>> cat: x: Permission denied
>> $ chmod 600 x
>> cat x
>> foo
>
>Rick:
>Looking at a tcpdump capture of the NFS traffic from the Linux client it seems to be doing:
>
>1. Client -> Server:
>
>V4 Procedure: COMPOUND (1)
>        SEQUENCE (53)
>        PUTFH (22)
>        OPEN (18)
>                share_access: OPEN4_SHARE_ACCESS_WRITE
>                open type: OPEN4_NOCREATE
>        ACCESS (3)
>                Check: RD MD XT XE
>        GETATTR (9)
>
>
>2. Server -> Client:
>
>V4 Procedure: COMPOUND (1)
>Status: NFS4_OK
>Operations (5):
>    SEQUENCE (53)
>        Status: NFS4_OK
>    PUTFH
>        Status: NFS4_OK
>    OPEN
>        Status: NFS4_OK
>    ACCESS [Access Denied]
Yep, this should tell Linux to fail, so I'd call this a Linux
client bug. (Without looking at the spec., I'm pretty
sure Access is supposed to return NFS_OK and the
kinds of access allowed and not fail with NFSERR_ACESS.

>        Status: NFS4_OK
>    GETATTR
>        Status: NFS4_OK
>
>
>3. Client -> Server:
>
>V4 Procedure: COMPOUND (1)
>Tag: <EMPTY>
>Operations:
>        SEQUENCE (53)
>       PUTFH (22)
>        WRITE (38)
>                Stable: FILE_SYNC4
>        GETATTR (9)
>
>
>4. Server -> Client
>
>V4 Procedure: COMPOUND
>Tag: <EMPTY>
>Operations:
>        SEQUENCE (53)
>                Status: NFS4_OK
>        PUTFH
>                Status: NFS4_OK
>        WRITE
>                Status: NFS4_OK
>                Committed: FILE_SYNC4
>        GETATTR
>                Status: NFS4_OK
Yep. NFS servers normally/always allow the owner of a
file to do read/write irrespective of permissions.
Why?
Well, a POSIX file system only checks permissions upon
open(2). Many POSIX apps then change permissions but continue
to do I/O as allowed by the open(2).

NFS is not POSIX compliant and does not do a POSIX
open(2). (NFSv3 has no open and NFSv4 has an open
that is basically a Windoze open/lock, or whatever they
call it.)

If an NFS server does not allow the owner access for I/O,
then all those POSIX apps. break and users do not like
the "NFS is not POSIX complaint" answer for why.

The Linux folks might argue that the NFSv4 Open should
fail, however I'd argue that it is not a POSIX open and
might not be performed at POSIX open time by the client.
(With delegations enabled, the Open does not even need
 to be done.)

The "owner has access" has been standard practice for NFS
servers for decades.

rick

(According to Wireshark)


Looks like Linux ignores the Access Denied in packet 2 and just forges ahead, and FreeBSD happily accepts the WRITE in packet 3…

- Peter


> On 27 Feb 2020, at 22:03, Peter Eriksson <pen at lysator.liu.se> wrote:
>
> I can verify that this indeed seems to be the case - the file owner can always write to files, no matter the permissions set.
>
> Tested both locally (on ZFS) and over NFS (from the same directory).