Linux could write to read only files on FreeBSD NFS server

[Luoqi Chen]

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.

Even if this is a linux bug, given its dominant position, we don't have
much of a choice but to try to be compatible. Does anyone have say access
to a netapp and see how it behaves?

-luoqi

On Thu, Feb 27, 2020 at 2:38 PM Rick Macklem <rmacklem at uoguelph.ca> wrote:

> 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).
>
> _______________________________________________
> 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"
>