From owner-freebsd-fs@freebsd.org Thu Feb 27 22:59:08 2020 Return-Path: Delivered-To: freebsd-fs@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CDC182521FA for ; Thu, 27 Feb 2020 22:59:08 +0000 (UTC) (envelope-from luoqi.chen@gmail.com) Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48T7QM0lSxz45mR for ; Thu, 27 Feb 2020 22:59:06 +0000 (UTC) (envelope-from luoqi.chen@gmail.com) Received: by mail-ot1-x332.google.com with SMTP id b3so851274otp.4 for ; Thu, 27 Feb 2020 14:59:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eaZs2SLxn1JqqfMHH3vq6RRx+abSQ6+cqjIjzK3s7rU=; b=RG2/iMPfgLjYgIO7hU1kvVSPe3iKwoti6mNdihj27WsWTmUtsmJb2YKQRUe8i/hr4v 5LCe5xfCVn5gZIGRm02T1NCaAVpIke4t8V5lOFka/LjhX2TykhN5UHBlsS3TdvSAzhSn bBvfTVTQw7w2nExrnxweARAEiDbxm+47fK/P24w1VdpajhzU6en8Hh2XARULDqJ8d1Lm P+M+cqGJS5o1vQpf/5itbnBUg7E3fIROACoBYGxHVS4df+XdRvTQ4Z3nK5DLQS1kc/6Q QuJSWeXNUy9lyxiz2ncMiHGvbR7wpcxUe165UK4y4Kn6GZeyo3XJA/377Xg4a+vwKHsE nUnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eaZs2SLxn1JqqfMHH3vq6RRx+abSQ6+cqjIjzK3s7rU=; b=WOOwr/Sf7Bp+0uPYh9kH/4rGpcyxqu21zPa7p14id5kg9ai7K6AahLEL6Z71pr22/D FhvbPHfljgj9PTFT6/9lHxzlAXnz70kEO7hz/HgpURQuDEiloXqI5tfsxXJFGO0Od+q0 mrkuR5UrciPYQ/b48LwisA88S8FJTiOWVZWwJsJwNpDfud2CGp/E1z9dxPwM37SDjmqF 5J+MLmT6xsYQoQK2/OWANZkCYrRvQgEy1VuEcoJ2rVbxUoZrzO5HYnF+vTDD9fBOklvN v/4DZpSjmWnuo3GO0+naONEgYbaV8L3xB9xO0cUuZkxn/chXJYB3DX9zETDDe8Ra5/Zu zOxA== X-Gm-Message-State: APjAAAWiFgSPmjIPzKkdqwmnqn0DQIjJh3BRx1W1WtY3NBuj1/D9gNLK ujl1aXQ6htrVPflI9PAmvaBWnF3+cM8xJatMsCrtZA== X-Google-Smtp-Source: APXvYqwc1Rh2Fnf0atID5vHsLrN/HxLRgHUCYkTlG9Gw9l+GVowddlHIQ9DWn+kMEj4Vb1Y1lFx2ixN6FbMpziQNCC4= X-Received: by 2002:a9d:3df6:: with SMTP id l109mr978477otc.284.1582844345551; Thu, 27 Feb 2020 14:59:05 -0800 (PST) MIME-Version: 1.0 References: <707243CD-C67E-4DAD-AC5A-68EC11CFFDFD@lysator.liu.se> <6EC06026-DA28-4CAC-8D56-5C7856D4625E@lysator.liu.se> In-Reply-To: From: Luoqi Chen Date: Thu, 27 Feb 2020 14:58:55 -0800 Message-ID: Subject: Re: Linux could write to read only files on FreeBSD NFS server To: Rick Macklem Cc: Peter Eriksson , FreeBSD Filesystems X-Rspamd-Queue-Id: 48T7QM0lSxz45mR X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=RG2/iMPf; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of luoqichen@gmail.com designates 2607:f8b0:4864:20::332 as permitted sender) smtp.mailfrom=luoqichen@gmail.com X-Spamd-Result: default: False [-2.00 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; FREEMAIL_FROM(0.00)[gmail.com]; URI_COUNT_ODD(1.00)[5]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(0.00)[ip: (-8.51), ipnet: 2607:f8b0::/32(-1.88), asn: 15169(-1.67), country: US(-0.05)]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-fs@freebsd.org]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2.3.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Feb 2020 22:59:08 -0000 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 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: > >Operations: > > SEQUENCE (53) > > PUTFH (22) > > WRITE (38) > > Stable: FILE_SYNC4 > > GETATTR (9) > > > > > >4. Server -> Client > > > >V4 Procedure: COMPOUND > >Tag: > >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 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" >