Date: Thu, 27 Feb 2020 14:58:55 -0800 From: Luoqi Chen <luoqi.chen@gmail.com> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: 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: <CAHJqQjsP-w9LAS4AV64Pu9Jmv0kVFodKdT_jLUcyop3sNVh_EA@mail.gmail.com> In-Reply-To: <YTBPR01MB3374713F573B548791A22F98DDEB0@YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM> References: <CAHJqQjuEVpL4xV1dAf6scFqFfMNm1gY3jOaO64ZQJTCQi_qzcQ@mail.gmail.com> <707243CD-C67E-4DAD-AC5A-68EC11CFFDFD@lysator.liu.se> <6EC06026-DA28-4CAC-8D56-5C7856D4625E@lysator.liu.se> <YTBPR01MB3374713F573B548791A22F98DDEB0@YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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=E2=80=99s not related to ACLs (atleast not directly). Using =E2= =80=9Cchmod=E2=80=9D > 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=E2=80=A6 > > - 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). > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAHJqQjsP-w9LAS4AV64Pu9Jmv0kVFodKdT_jLUcyop3sNVh_EA>