From owner-freebsd-fs@freebsd.org Thu Feb 27 22:37:59 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 5402A251BD0 for ; Thu, 27 Feb 2020 22:37:59 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660079.outbound.protection.outlook.com [40.107.66.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48T6xv5hxWz47xm for ; Thu, 27 Feb 2020 22:37:55 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ih7cp4NsF4swsGTteu0odpRieZJiH499gdDE//v5L+yn4aB3/4K7yaoyoBHV5m0CjygO3RLtZMPjxHXnjdpvmoSchUIKrn/Ntgvh+wbbb+N0pnCYGL7tAdbEiTy1AE551x/k/XTZPXQAaCijGDoe9jLeDJw3VsDx95LnnlEomvY/4dt5Q+i/3E52jN3tX6s0vd3xs76G2TPBvua7t6sD5pCxg2VOwREKBlUSQ11+3NmQvZKnt+tKZqDly641TajyCsO/zO+o1D+7oco+irCHF0tD8izJSKngmfPK29NpgXb+WVi/rNzN2x+Z8pY6vECbEXSVmJqh8jVcAAp0V/XWQg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=lbgUN0QdCFB16PeK+T1uZzK080Ztvyp0S1glxcNibio=; b=jxw4cyj5pD387OKr1ba+ZQpW+uS7/tLzSsvCJdYB9PsyZlhUwLS22D/3qBO75Mv88+S8eAyUe5sfuAJKBp/YchIlf6IlPGOY4atYBglPqUsI8yAFmspuMqM7Vk/Wg3/24qmihHypANEHe59qUcw9lrC2IEQVA3nvV9lcJRa/KR84aSTOInjsnuVJGGX4M1rvBYyMO5dh1UvhRWhtYcvTfydziD6Eu4W55OZsw2f1Yg6yfIzTJ94ffGOgUo1iS1VdLEqYZCCfHXCc1DrA+dTGUXjaPKZZDE2YK/7SAjpZtrt67vwsflN+ZypnYKF7Rd22cJYH37t9YYps4LtN/pMveA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none Received: from YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM (10.255.46.82) by YTBPR01MB3536.CANPRD01.PROD.OUTLOOK.COM (10.255.47.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.14; Thu, 27 Feb 2020 22:37:53 +0000 Received: from YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM ([fe80::a50d:6237:4074:f9c4]) by YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM ([fe80::a50d:6237:4074:f9c4%6]) with mapi id 15.20.2772.012; Thu, 27 Feb 2020 22:37:43 +0000 From: Rick Macklem To: Peter Eriksson , FreeBSD Filesystems Subject: Re: Linux could write to read only files on FreeBSD NFS server Thread-Topic: Linux could write to read only files on FreeBSD NFS server Thread-Index: AQHV7ZU6To48aBpgW0mPQBk2wdIrMagvh4MAgAATIQCAAALPjQ== Date: Thu, 27 Feb 2020 22:37:42 +0000 Message-ID: References: <707243CD-C67E-4DAD-AC5A-68EC11CFFDFD@lysator.liu.se>, <6EC06026-DA28-4CAC-8D56-5C7856D4625E@lysator.liu.se> In-Reply-To: <6EC06026-DA28-4CAC-8D56-5C7856D4625E@lysator.liu.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f20e488a-f2ac-4c3a-5329-08d7bbd5a8c8 x-ms-traffictypediagnostic: YTBPR01MB3536: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 03264AEA72 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(376002)(396003)(366004)(346002)(136003)(199004)(189003)(55016002)(52536014)(91956017)(76116006)(86362001)(7696005)(53546011)(66476007)(9686003)(66556008)(64756008)(66946007)(81166006)(81156014)(8936002)(478600001)(71200400001)(66446008)(5660300002)(786003)(8676002)(6506007)(110136005)(26005)(186003)(2906002)(296002)(316002)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:YTBPR01MB3536; H:YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Twx4gBnwmOywpHfBz+/XpIl4j4C0/ZtduG3q4v7xQPUY8erpxY7xgndxZEFEum5RV0pdOpfdt7ro57Y0zF5fCNzoCHkyrNEJH1fUM2+NuIBEdyN665tHKCO8iLwzqwFpeQYtNJckSZr0BViefcy3F0VOy5UrUCyIVe1cQDhJUIoI2iR1gkZlbXNVX/U2X0aNzG7akCo3Y55Hwvl9ho5XAvr7c9DnuzK7whVrFOrH3IM2JXHIFL1Y1pbGZsdOfRKgMCtwl2evcJbm8TeJccAr92W9w60pCjZQcbH31QQkRGEC4BA0u0krIHvM+NwDWITto08UTFLkBqLJe1BYq7HxxpH4KwQILyyorrP0yQ4+U+LSbxJwww+nNgBwxCo8FHCILj4bxGHGWxqS+Oq2DyOVnqT5oWYgbAAYYIuOKfkk8FqyA27Se4JFk/aTH7i/zgQJ x-ms-exchange-antispam-messagedata: t5uUmGu6igQTjFXJzV3b0eIJT/Xeh4q5wBgCsnU4/16FzbPfArhMZzMYu0gkYUxE0qwDn6O2b7cB4I/4FBRtc0ANOCz+PnD9Vqrj6ySsb1YGN0t8SCFwGx8qlC0c2Lbe52y3ZW0TIO6USEQOEq2umg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: f20e488a-f2ac-4c3a-5329-08d7bbd5a8c8 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2020 22:37:42.9873 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: DlLJ09wZAhWrKSh+YH5r8N/TycxXwSKbpdLti4+sGTfnRi+MRHf8xnRf9OCX5EnwT+2tMyQhO3iY/UcHhgRpdg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTBPR01MB3536 X-Rspamd-Queue-Id: 48T6xv5hxWz47xm X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.66.79 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-4.70 / 15.00]; RCVD_TLS_LAST(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[uoguelph.ca]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[79.66.107.40.list.dnswl.org : 127.0.3.0]; IP_SCORE(-1.40)[ipnet: 40.64.0.0/10(-3.83), asn: 8075(-3.12), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8075, ipnet:40.64.0.0/10, country:US]; ARC_ALLOW(-1.00)[i=1] 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:37:59 -0000 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: =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: =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 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=