[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[nfsv4] re: ACL and Posix Mode bit interaction
I'm a simple minded guy and I got lost on this so long ago it isn't worth
mentioning. So, I'm going to throw out what I think should be done. I don't
expect anyone to buy into it, but you asked for comments before the meeting,
so here goes...
I don't think the RFC should say anything about how the client chooses to
handle the Mode and ACL attributes. If a posix-like client wants to set
both an ACL and Mode bits for chmod(2) syscall, that is up to the client
implementors.
(All comments w.r.t. RFC3530)
I think what goes on the wire is pretty clear, so I think what is left is
to clarify what the server does w.r.t. Mode and ACL:
Since doing a Setattr on any other attribute only "Sets" that attribute,
I believe that the same should be true of Mode and ACL. (In other words,
toss Sec. 5.11.6, because I think the seemingly endless discussion is
evidence that you can't do it right and any attempt just causes endless
confusion.)
That leaves:
- The "access is undefined" case for bits left over (3rd para of 5.11).
- I can see three possibilities. I don't care which of the 3 is chosen,
but I do think interoperability would be enhanced by choosing one of
them.
- Deny
- Allow
- Use the Posix mask bits (My current server code does this, but I am
not strongly in favour of it.)
- What about the case where no ACL has been set on the file. I would have
preferred that the server just not return an ACL, but since Sec. 14.2.7
doesn't allow that, so...
Define the ACL with no entries as "No ACL for this file". (empty ACL)
(If Windows has a different notion of what an empty ACL is, then the
Windows clients can deal with that case by generating a non-empty ACL that
represents what Windows considers an empty ACL to mean.)
- How a server uses Mode and ACL for permission checking?
- If there is an ACL for the file
- use the ACL and ignore the Mode bits
else /* empty ACL, as above */
- use the Mode bits
Just my opinion on a simple way to deal with the problem, rick
_______________________________________________
nfsv4 mailing list
nfsv4 at ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4