Re: [nfsv4] Fwd: New Version Notification for draft-dnoveck-nfsv4-security-04.txt

On Tue, Jan 18, 2022, 10:53 AM Chuck Lever III <chuck.lever@oracle.com>
wrote:

>
> > On Jan 17, 2022, at 9:52 AM, J. Bruce Fields <bfields@fieldses.org>
> wrote:
> > On Sun, Jan 16, 2022 at 04:03:12AM -0500, David Noveck wrote:
> >> It seems to me that, given the absence, of an append-write in the NFSv4
> >> protocol, APPEND_WRITE belongs in the same bucket as SYNCHRONIZE and I
> am
> >> planning to draft -05 on that basis.
> >>
> >> Looking forward to -06, I'd like to get away from the text which makes
> each
> >> mask bit its own optional feature,. Clearly READ_DATA, WRITE _DATA, and
> >> EXECUTE should be mandatory but what about the others?  Should any of
> these
> >> be mandatory?  If not, why isn't it implemented? Are there
> >> applications/clients that rely on it?
> >
> > Again, I don't agree that it's desirable to specify this level of
> > detail.
> >
> > NFS has always been a protocol which allows exporting filesystems with
> > semantics that vary somewhat.
> >
> > I'd recommend instead thinking hard about what's essential to do in this
> > document and looking for ways to reduce its scope and length.
> >
> > We've got limited resources, and the attempt to produce a really
> > detailed synthesis of unix and Windows permissions models is an
> > ambitious project.
>
> I enthusiastically endorse moving security-related material into its own
> document.
>
> However, I do not support specifying ACL to mode translation in detail.
> The nfsv4 working group has no authority to mandate policy in local file
> system implementations.

It does have the authority to mandate the behavior exposed to the client
peer.  In this context the server's filesystem is part of the server.  In
any case, server code outside the fs could provide the necessary mapping.

The protocol‘s role is to expose those policies to applications running on
> clients.

This approach would throw interoperability under the bus.

>
>
> I can get behind the document discussing general issues and providing
> clarifying examples in such a way that cannot be mistaken for normative
> text.
>
>
> > --b.
> >
> >>
> >> On Fri, Jan 14, 2022, 6:48 PM Rick Macklem <rmacklem@uoguelph.ca>
> wrote:
> >>
> >>> J. Bruce Fields wrote:
> >>>> On Sun, Jan 09, 2022 at 11:15:34PM +0000, Rick Macklem wrote:
> >>>>> From: David Noveck wrote:
> >>>>>> If I understand correctly, you are intending to accept an acl that
> >>> APPEND_DATA and not
> >>>>>> WRITE_DATA  and then not let the user open the file for write.   I
> >>> don't know about your
> >>>>>> users but I would certainly feel that was a "weird, irritating
> >>> inconsistency".
> >>>>> Yes, but it is consistent with local behaviour on FreeBSD.
> >>>>> A file with APPEND_DATA, but not WRITE_DATA cannot be open'd with a
> >>> POSIX
> >>>>> open("foo", O_APPEND | O_WRONLY, 0)
> >>>>> either locally nor over NFS.
> >>>>> (O_APPEND is a modifier and cannot be specified by itself.)
> >>>> How would an NFS client write to it, anyway?  Do you just tell people
> >>>> they need to use O_SYNC for such files?
> >>> When a file is POSIX open(...O_APPEND..)'d in FreeBSD on an NFS mount
> >>> point, each write is pushed through to the server (with an exclusive
> lock
> >>> held on the vnode) FILESYNC.
> >>> The result maintains ordering, but is very slow compared to doing the
> >>> same on local file systems. For a test case doing 10,000 writes, it
> >>> takes 13sec over NFS vs 0.3sec locally for UFS (even slower for ZFS,
> >>> takes 2minutes for ZFS with sync enabled and no ZIL log).
> >>>> Otherwise writes are likely to get reordered, and then the writer gets
> >>>> random EACCES (and random unfillable holes, if you allow writes at
> >>>> offsets past EOF).  Seems like a bit of a foot-gun.
> >>> Yep, it forces O_SYNC basically.
> >>>> Oh well, out of scope here, I suppose.
> >>> Not really. If another client writes to the file, it could still get
> >>> "random"
> >>> EACCES failures.
> >>> As I mentioned, the FreeBSD server stores APPEND_DATA, but ignores it.
> >>> I recall Robert Watson (who designed the FreeBSD NFSv4 ACL stuff)
> >>> stating as the reason "because it's such a pita".
> >>> For FreeBSD, this is also true of ZFS. (The ACL enforcing part of ZFS
> >>> is in the port specific code, so I don't know what Linux/Solaris does
> >>> w.r.t. APPEND_DATA for ZFS.)
> >>> rick
> >>> --b.
> >
> > _______________________________________________
> > nfsv4 mailing list
> > nfsv4@ietf.org
> > https://www.ietf.org/mailman/listinfo/nfsv4
>