Linux could write to read only files on FreeBSD NFS server

[Rick Macklem]

Luoqi Chen wrote:
>On Fri, Feb 28, 2020 at 3:13 AM Martin Simmons ><martin at lispworks.com<mailto:martin at lispworks.com>> wrote:
>>>>>> On Thu, 27 Feb 2020 14:58:55 -0800, Luoqi Chen said:
>>
>> 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.
>
>Have you tried mounting it with nfsv3 recently?  I can't repeat it with that
>version (I don't run nfsv4 at all).
>
>Looks like I'm getting senile... The script works correctly with nfsv3 mounts. This is
>a nfsv4 specific problem.
Ok, I've re-read the Open section of the NFSv4 RFCs. They all have similar wording.
I can see how it can be interpreted multiple ways. Here's the RFC 5661 snippet:

   Based on the share_access value (OPEN4_SHARE_ACCESS_READ,
   OPEN4_SHARE_ACCESS_WRITE, or OPEN4_SHARE_ACCESS_BOTH), the client
   should check that the requester has the proper access rights to
   perform the specified operation.  This would generally be the results
   of applying the ACL access rules to the file for the current
   requester.  However, just as with the ACCESS operation, the client
   should not attempt to second-guess the server's decisions, as access
   rights may change and may be subject to server administrative
   controls outside the ACL framework.  If the requester's READ or WRITE
   operation is not authorized (depending on the share_access value),
   the server MUST return NFS4ERR_ACCESS.

Now, I had interpreted the last sentence meaning "apply the same check
as Read/Write does". Since the owner of the file is always allowed to Read/Write
(as explained in a previous post), that is what the FreeBSD NFSv4 server does.
However, I can see that it could be interpreted as "return NFS4ERR_ACCESS if
the file modes/ACL would result in an EACCES error".
--> As such, although it could result in an inconsistency between NFSv3 and
       NFSv4, I could see the Linux client depending on that instead of using
       the replied information for the Access operation to decide if a POSIX
       Open should be allowed.

Anyhow, I've attached a trivial patch that changes the NFSv4 Open semantics
to conform to what the mode/ACL indicates.
I am not sure that this patch should be applicable to head, but if it makes the
Linux client happy, I can see it being optionally enabled via a sysctl.

Please let me know if you can test the patch and determine if the Linux NFSv4
mount works with the patched FreeBSD server.

rick
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ownerover.patch
Type: application/octet-stream
Size: 1433 bytes
Desc: ownerover.patch
URL: <http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20200302/cf805c0c/attachment.obj>