Date: Thu, 27 Feb 2020 22:37:42 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: Peter Eriksson <pen@lysator.liu.se>, FreeBSD Filesystems <freebsd-fs@freebsd.org> Subject: Re: Linux could write to read only files on FreeBSD NFS server Message-ID: <YTBPR01MB3374713F573B548791A22F98DDEB0@YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <6EC06026-DA28-4CAC-8D56-5C7856D4625E@lysator.liu.se> References: <CAHJqQjuEVpL4xV1dAf6scFqFfMNm1gY3jOaO64ZQJTCQi_qzcQ@mail.gmail.com> <707243CD-C67E-4DAD-AC5A-68EC11CFFDFD@lysator.liu.se>, <6EC06026-DA28-4CAC-8D56-5C7856D4625E@lysator.liu.se>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YTBPR01MB3374713F573B548791A22F98DDEB0>