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:=0A= >I see that this was a bit unclear, writing to the protected file was via N= FS from a Linux (CentOS >7) client. I verified the ACLs and the file conten= t both via NFSv4 and locally on the FreeBSD >server.=0A= >=0A= >Writing from an OmniOS (OpenSolaris) client fails. As does a local write. = As it should...=0A= >=0A= >Also, it=92s not related to ACLs (atleast not directly). Using =93chmod=94= gives the same effect:=0A= >=0A= >> $ rm -f x=0A= >> $ touch x=0A= >> $ chmod 000 x=0A= >> $ ls -l x=0A= >> ---------- 1 peter86 employee-liu.se 0 27 feb 22.46 x=0A= >> $ echo foo >x=0A= >> $ cat x=0A= >> cat: x: Permission denied=0A= >> $ chmod 600 x=0A= >> cat x=0A= >> foo=0A= >=0A= >Rick:=0A= >Looking at a tcpdump capture of the NFS traffic from the Linux client it s= eems to be doing:=0A= >=0A= >1. Client -> Server:=0A= >=0A= >V4 Procedure: COMPOUND (1)=0A= > SEQUENCE (53)=0A= > PUTFH (22)=0A= > OPEN (18)=0A= > share_access: OPEN4_SHARE_ACCESS_WRITE=0A= > open type: OPEN4_NOCREATE=0A= > ACCESS (3)=0A= > Check: RD MD XT XE=0A= > GETATTR (9)=0A= >=0A= >=0A= >2. Server -> Client:=0A= >=0A= >V4 Procedure: COMPOUND (1)=0A= >Status: NFS4_OK=0A= >Operations (5):=0A= > SEQUENCE (53)=0A= > Status: NFS4_OK=0A= > PUTFH=0A= > Status: NFS4_OK=0A= > OPEN=0A= > Status: NFS4_OK=0A= > ACCESS [Access Denied]=0A= Yep, this should tell Linux to fail, so I'd call this a Linux=0A= client bug. (Without looking at the spec., I'm pretty=0A= sure Access is supposed to return NFS_OK and the=0A= kinds of access allowed and not fail with NFSERR_ACESS.=0A= =0A= > Status: NFS4_OK=0A= > GETATTR=0A= > Status: NFS4_OK=0A= >=0A= >=0A= >3. Client -> Server:=0A= >=0A= >V4 Procedure: COMPOUND (1)=0A= >Tag: <EMPTY>=0A= >Operations:=0A= > SEQUENCE (53)=0A= > PUTFH (22)=0A= > WRITE (38)=0A= > Stable: FILE_SYNC4=0A= > GETATTR (9)=0A= >=0A= >=0A= >4. Server -> Client=0A= >=0A= >V4 Procedure: COMPOUND=0A= >Tag: <EMPTY>=0A= >Operations:=0A= > SEQUENCE (53)=0A= > Status: NFS4_OK=0A= > PUTFH=0A= > Status: NFS4_OK=0A= > WRITE=0A= > Status: NFS4_OK=0A= > Committed: FILE_SYNC4=0A= > GETATTR=0A= > Status: NFS4_OK=0A= Yep. NFS servers normally/always allow the owner of a=0A= file to do read/write irrespective of permissions.=0A= Why?=0A= Well, a POSIX file system only checks permissions upon=0A= open(2). Many POSIX apps then change permissions but continue=0A= to do I/O as allowed by the open(2).=0A= =0A= NFS is not POSIX compliant and does not do a POSIX=0A= open(2). (NFSv3 has no open and NFSv4 has an open=0A= that is basically a Windoze open/lock, or whatever they=0A= call it.)=0A= =0A= If an NFS server does not allow the owner access for I/O,=0A= then all those POSIX apps. break and users do not like=0A= the "NFS is not POSIX complaint" answer for why.=0A= =0A= The Linux folks might argue that the NFSv4 Open should=0A= fail, however I'd argue that it is not a POSIX open and=0A= might not be performed at POSIX open time by the client.=0A= (With delegations enabled, the Open does not even need=0A= to be done.)=0A= =0A= The "owner has access" has been standard practice for NFS=0A= servers for decades.=0A= =0A= rick=0A= =0A= (According to Wireshark)=0A= =0A= =0A= Looks like Linux ignores the Access Denied in packet 2 and just forges ahea= d, and FreeBSD happily accepts the WRITE in packet 3=85=0A= =0A= - Peter=0A= =0A= =0A= > On 27 Feb 2020, at 22:03, Peter Eriksson <pen@lysator.liu.se> wrote:=0A= >=0A= > I can verify that this indeed seems to be the case - the file owner can a= lways write to files, no matter the permissions set.=0A= >=0A= > Tested both locally (on ZFS) and over NFS (from the same directory).=0A= =0A=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YTBPR01MB3374713F573B548791A22F98DDEB0>