Date: Mon, 2 Mar 2020 00:19:32 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: Luoqi Chen <luoqi.chen@gmail.com>, Martin Simmons <martin@lispworks.com> Cc: freebsd-fs <freebsd-fs@freebsd.org> Subject: Re: Linux could write to read only files on FreeBSD NFS server Message-ID: <YTBPR01MB337401285CAA695E1D7AA5BADDE70@YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <CAHJqQjt4M_j5=85wcb2hcMC7nepV0ktAtOxbinvj%2BVv2cFWG5g@mail.gmail.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> <CAHJqQjsP-w9LAS4AV64Pu9Jmv0kVFodKdT_jLUcyop3sNVh_EA@mail.gmail.com> <202002281113.01SBDlsl017697@higson.cam.lispworks.com>, <CAHJqQjt4M_j5=85wcb2hcMC7nepV0ktAtOxbinvj%2BVv2cFWG5g@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--_002_YTBPR01MB337401285CAA695E1D7AA5BADDE70YTBPR01MB3374CANP_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Luoqi Chen wrote:=0A=
>On Fri, Feb 28, 2020 at 3:13 AM Martin Simmons ><martin@lispworks.com<mail=
to:martin@lispworks.com>> wrote:=0A=
>>>>>> On Thu, 27 Feb 2020 14:58:55 -0800, Luoqi Chen said:=0A=
>>=0A=
>> One more piece of information that might help: this behavior started=0A=
>> somewhere between centos 5 and 6, kernel 2.6.18 and 2.6.32, i.e., the sa=
me=0A=
>> script would fail on 2.6.18. Timing wise I believe it coincided with the=
=0A=
>> introduction of nfsv4.=0A=
>=0A=
>Have you tried mounting it with nfsv3 recently? I can't repeat it with th=
at=0A=
>version (I don't run nfsv4 at all).=0A=
>=0A=
>Looks like I'm getting senile... The script works correctly with nfsv3 mou=
nts. This is=0A=
>a nfsv4 specific problem.=0A=
Ok, I've re-read the Open section of the NFSv4 RFCs. They all have similar =
wording.=0A=
I can see how it can be interpreted multiple ways. Here's the RFC 5661 snip=
pet:=0A=
=0A=
Based on the share_access value (OPEN4_SHARE_ACCESS_READ,=0A=
OPEN4_SHARE_ACCESS_WRITE, or OPEN4_SHARE_ACCESS_BOTH), the client=0A=
should check that the requester has the proper access rights to=0A=
perform the specified operation. This would generally be the results=0A=
of applying the ACL access rules to the file for the current=0A=
requester. However, just as with the ACCESS operation, the client=0A=
should not attempt to second-guess the server's decisions, as access=0A=
rights may change and may be subject to server administrative=0A=
controls outside the ACL framework. If the requester's READ or WRITE=0A=
operation is not authorized (depending on the share_access value),=0A=
the server MUST return NFS4ERR_ACCESS.=0A=
=0A=
Now, I had interpreted the last sentence meaning "apply the same check=0A=
as Read/Write does". Since the owner of the file is always allowed to Read/=
Write=0A=
(as explained in a previous post), that is what the FreeBSD NFSv4 server do=
es.=0A=
However, I can see that it could be interpreted as "return NFS4ERR_ACCESS i=
f=0A=
the file modes/ACL would result in an EACCES error".=0A=
--> As such, although it could result in an inconsistency between NFSv3 and=
=0A=
NFSv4, I could see the Linux client depending on that instead of usi=
ng=0A=
the replied information for the Access operation to decide if a POSI=
X=0A=
Open should be allowed.=0A=
=0A=
Anyhow, I've attached a trivial patch that changes the NFSv4 Open semantics=
=0A=
to conform to what the mode/ACL indicates.=0A=
I am not sure that this patch should be applicable to head, but if it makes=
the=0A=
Linux client happy, I can see it being optionally enabled via a sysctl.=0A=
=0A=
Please let me know if you can test the patch and determine if the Linux NFS=
v4=0A=
mount works with the patched FreeBSD server.=0A=
=0A=
rick=0A=
--_002_YTBPR01MB337401285CAA695E1D7AA5BADDE70YTBPR01MB3374CANP_
Content-Type: application/octet-stream; name="ownerover.patch"
Content-Description: ownerover.patch
Content-Disposition: attachment; filename="ownerover.patch"; size=1433;
creation-date="Mon, 02 Mar 2020 00:19:17 GMT";
modification-date="Mon, 02 Mar 2020 00:19:17 GMT"
Content-Transfer-Encoding: base64
LS0tIGZzL25mc3NlcnZlci9uZnNfbmZzZHNlcnYuYy5vd25lcm92ZXIJMjAyMC0wMy0wMSAwNzoy
MDoxOC41NzYwNTIwMDAgLTA4MDAKKysrIGZzL25mc3NlcnZlci9uZnNfbmZzZHNlcnYuYwkyMDIw
LTAzLTAxIDA3OjUxOjAwLjE2MjI2NjAwMCAtMDgwMApAQCAtMjc4NCw3ICsyNzg0LDcgQEAgbmZz
cnZkX29wZW4oc3RydWN0IG5mc3J2X2Rlc2NyaXB0ICpuZCwgX191bnVzZWQgaW50IGlzCiAJdV9p
bnQzMl90ICp0bDsKIAlpbnQgaSwgcmV0ZXh0OwogCXN0cnVjdCBuZnNzdGF0ZSAqc3RwID0gTlVM
TDsKLQlpbnQgZXJyb3IgPSAwLCBjcmVhdGUsIGNsYWltLCBleGNsdXNpdmVfZmxhZyA9IDA7CisJ
aW50IGVycm9yID0gMCwgY3JlYXRlLCBjbGFpbSwgZXhjbHVzaXZlX2ZsYWcgPSAwLCBvdmVycmlk
ZTsKIAl1X2ludDMyX3QgcmZsYWdzID0gTkZTVjRPUEVOX0xPQ0tUWVBFUE9TSVgsIGFjZW1hc2s7
CiAJaW50IGhvdyA9IE5GU0NSRUFURV9VTkNIRUNLRUQ7CiAJaW50MzJfdCBjdmVyZlsyXSwgdHZl
cmZbMl0gPSB7IDAsIDAgfTsKQEAgLTMwODgsMTUgKzMwODgsMTYgQEAgbmZzcnZkX29wZW4oc3Ry
dWN0IG5mc3J2X2Rlc2NyaXB0ICpuZCwgX191bnVzZWQgaW50IGlzCiAJCSAqLwogCQluZC0+bmRf
cmVwc3RhdCA9ICh2cC0+dl90eXBlID09IFZESVIpID8gTkZTRVJSX0lTRElSIDogTkZTRVJSX1NZ
TUxJTks7CiAJfQorCW92ZXJyaWRlID0gTkZTQUNDQ0hLX05PT1ZFUlJJREU7CiAJaWYgKCFuZC0+
bmRfcmVwc3RhdCAmJiAoc3RwLT5sc19mbGFncyAmIE5GU0xDS19XUklURUFDQ0VTUykpCiAJICAg
IG5kLT5uZF9yZXBzdGF0ID0gbmZzdm5vX2FjY2Noayh2cCwgVldSSVRFLCBuZC0+bmRfY3JlZCwK
LQkgICAgICAgIGV4cCwgcCwgTkZTQUNDQ0hLX0FMTE9XT1dORVIsIE5GU0FDQ0NIS19WUElTTE9D
S0VELCBOVUxMKTsKKwkgICAgICAgIGV4cCwgcCwgb3ZlcnJpZGUsIE5GU0FDQ0NIS19WUElTTE9D
S0VELCBOVUxMKTsKIAlpZiAoIW5kLT5uZF9yZXBzdGF0ICYmIChzdHAtPmxzX2ZsYWdzICYgTkZT
TENLX1JFQURBQ0NFU1MpKSB7CiAJICAgIG5kLT5uZF9yZXBzdGF0ID0gbmZzdm5vX2FjY2Noayh2
cCwgVlJFQUQsIG5kLT5uZF9jcmVkLAotCSAgICAgICAgZXhwLCBwLCBORlNBQ0NDSEtfQUxMT1dP
V05FUiwgTkZTQUNDQ0hLX1ZQSVNMT0NLRUQsIE5VTEwpOworCSAgICAgICAgZXhwLCBwLCBvdmVy
cmlkZSwgTkZTQUNDQ0hLX1ZQSVNMT0NLRUQsIE5VTEwpOwogCSAgICBpZiAobmQtPm5kX3JlcHN0
YXQpCiAJCW5kLT5uZF9yZXBzdGF0ID0gbmZzdm5vX2FjY2Noayh2cCwgVkVYRUMsCi0JCSAgICBu
ZC0+bmRfY3JlZCwgZXhwLCBwLCBORlNBQ0NDSEtfQUxMT1dPV05FUiwKKwkJICAgIG5kLT5uZF9j
cmVkLCBleHAsIHAsIG92ZXJyaWRlLAogCQkgICAgTkZTQUNDQ0hLX1ZQSVNMT0NLRUQsIE5VTEwp
OwogCX0KIAo=
--_002_YTBPR01MB337401285CAA695E1D7AA5BADDE70YTBPR01MB3374CANP_--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YTBPR01MB337401285CAA695E1D7AA5BADDE70>