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

[Trond Myklebust <[e-mail]>]

On Tue, 2022-01-18 at 14:06 -0500, David Noveck wrote:
> 
> 
> On Mon, Jan 17, 2022, 9:51 AM J. Bruce Fields <[e-mail]>
> 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.
> 
> I take it that you agree with that.

I don't. The restriction on extending the file can still be enforced by
the server even without there being an explicit APPEND_WRITE operation.

One use case would be for swap over NFS.

> 
> > > 
> > > 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
> 
> Do you disagree with that.
> 
> 
> >  but what about the others?  Should any of these
> > > be mandatory?
> 
> It appears that you don't think they should.
> 
> 
> >   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.
> 
> I don't see how you can avoid it. I can see it is undesirable but all
> those mask bits are in the spec.  This undesirable level of detail is
> there and I can't see specifying it and then essentially saying,
> obtw, you can pretty much ignore all of the above and clients just
> have to deal with it.
> 
> > 
> > NFS has always been a protocol which allows exporting filesystems
> > with
> > semantics that vary somewhat.
> 
> It was able to do that because, for most of its lifetime it was a
> purely unix-oriented protocol and did not try to produce an IETF
> proposed standard to enable compatible implementations to be
> produced.  Sigh!
> 
> > 
> > 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.
> 
> The scope and length are the result of decisions made in writing RFCs
> 3530 and 5661.
> 
> > 
> > We've got limited resources, and the attempt to produce a really
> > detailed synthesis of unix and Windows permissions models is an
> > ambitious project.
> 
> It was overambitious and I and others involved failed to point out
> this problem before this was published.  I realize this puts the
> working group in an unfortunate situation but we are where we are.
> 
> I believe the best way forward is to look at the windows support
> features as an optional extra and define clearly the Unix oriented
> subset that clients can rely on.
> 

Do we have any indication that clients have a problem with the current
ACLs? My own testing, with Hammerspace systems that are used for both
SMB and NFSv4 clients has not shown up any protocol level problems yet.



-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
[e-mail]