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

bfields@fieldses.org

Date: Thu, 16 Dec 2004 20:21:41 -0500
Subject: Re: [nfsv4] NFSv4 ACLs: {READ,WRITE}_NAMED_ATTRIBUTES
Message-ID: <20041217012141.GA12138@fieldses.org>
From: "J. Bruce Fields" <bfields@fieldses.org>

Bruce Fields wrote:
> > I think we should recommend that on posix->nfsv4 translation, 
> > we create acls with neither bit set in any allow or deny ace. 

On Thu, Dec 16, 2004 at 03:40:24PM -0800, Khan, Saadia wrote:
> 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.

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.

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4