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

["J. Bruce Fields" <[e-mail]>]

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.

--b.

> 
> On Fri, Jan 14, 2022, 6:48 PM Rick Macklem <[e-mail]> 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.
> >
> >