Subject: RE: [nfsv4] NFSv4 ACLs: {READ,WRITE}_NAMED_ATTRIBUTES

From: "Khan, Saadia" <[email-masked]>
Date: Thu, 16 Dec 2004 15:40:24 -0800

> -----Original Message-----
> From: J. Bruce Fields [mailto:[email-masked]] 
> Sent: Thursday, December 16, 2004 3:19 PM
> To: Lisa Week
> Cc: [email-masked]; Halevy, Benny; Gordon Waidhofer; 
> [email-masked]
> Subject: Re: [nfsv4] NFSv4 ACLs: {READ,WRITE}_NAMED_ATTRIBUTES
> 
> 
> On Thu, Dec 16, 2004 at 04:00:51PM -0700, Lisa Week wrote:
> > J. Bruce Fields wrote:
> > >On Thu, Dec 16, 2004 at 11:42:26AM -0800, Gordon Waidhofer wrote:
> > >
> > >>The question of NFSV4_{READ|WRITE}_NAMED_ATTRIBUTES
> > >>should be deferred for as long as possible, certainly
> > >>in the near term. Why? Simply because there is unspoken discord 
> > >>about what a named attribute is.
> > >
> > >I agree about the {READ|WRITE}_NAMED_ATTRIBUTES bits.
> > >
> > 
> > Just to be clear...What are we actually saying with "The question of
> > NFSV4_{READ|WRITE}_NAMED_ATTRIBUTES should be deferred for 
> as long as 
> > possible"?  Go with the I-D interpretation?  Leave them 
> unspecified? 
> > Something else?
> 
> I think we should recommend that on posix->nfsv4 translation, 
> we create acls with neither bit set in any allow or deny ace. 

So if a server has decided that not having a bit set in the access mask
means denying it, then it will always deny read and write of named
attributes? I don't believe that NFSV4_READ_NAMED_ATTRIBUTE is something
that should be allowed to everyone.

>  On nfsv4->posix translation we should ignore that bit 
> whenever possible, that is, whenver it doesn't force us into 
> a lie.  (A Linux server, for example, will reject an acl that 
> explicitly denies WRITE_NAMED_ATTRIBUTES when WRITE is 
> explicitly allowed.)
> 
> I think that's approximately what we already agreed on?
> 
> The point is that if clients follow the current I-D then they 
> force a certain permissions model onto servers, which is 
> probably a mistake.
> 
> --b.
> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/nfsv4
> 

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: "J. Bruce Fields" <[email-masked]>
Date: Thu, 16 Dec 2004 20:21:41 -0500

> that should be allowed to everyone.

Yes.  I'm don't think that's what you want to do.

There's obviously a diversity of named attribute implementations, and
they aren't all done yet.  Some of the people with named attributes also
want to use the posix acl support on their servers.

Take 3 hypothetical servers, A, B, and C:

Server A decides that it's going to determine permissions to read/write
its named attributes by looking at read/write bits on the file.

server B decides it's going to determine permissions to read/write
extended attributes in the way others on the list have suggested--write
to owner only, read to everyone.

Server C has full NFSv4 acl support, and allows the *_NAMED_ATTRIBUTE
bits to be set independently of the other bits.

How's a poor client to keep all three of these servers happy?  If it
follows the current mapping draft, server A will be happy, but server B
will be forced, if it is honest, to reject such ACLs.  If the client
instead cooks up ACLs that do what server B wants, then server A will be
unhappy.

The simplest solution would be for the client to just leave
{READ,WRITE}_NAMED_ATTRIBUTES unset and leave it up to the server;
servers A and B can accept such ACLs and enforce named attribute
permissions in the only way possible to them.  Server C is free to pick
some reasonable default.

For these purposes I'd think server C would want to pick the same sort
of default behaviour that it uses for mode bits; if it allows
WRITE_NAMED_ATTRIBUTES when a client sets the write mode bit, then I"d
think it'd want to do the same thing when translating an acl that allows
write but doesn't allow or deny WRITE_NAMED_ATTRIBUTES.

--b.

---

From: "Gordon Waidhofer" <[email-masked]>
Date: Thu, 16 Dec 2004 18:11:26 -0800

> bits to be set independently of the other bits.

All three of these examples assume that one set of permission bits
apply to all subfiles (named attributes). Probably the case
for present day NTFS, though there is some indication NTFS will
have to address security holes raised by streams (subfiles).

Solaris subfiles (extended attributes), on the other hand, are
much more fine grained. Each subfile has its own set of permissions.
Indeed, each subfile could have its own ACL, owner, mtime, ctime,
etc, etc.

The difference is no small point.

As much as I like the Solaris approach (quite aesthetic, though
misnamed), I have to worry about its influence on NFSv4 semantics.
The file model could easily become something NTFS can't or won't do.

I've no answers at this time. It would be nice if we knew more
about what NTFS is going to do about its subfile security holes.

So, restraint on anything and everything related to NFSv4 Named
Attributes (subfiles, that should be renamed too) is advisable.

Regards,
	-gww