Subject: [nfsv4] Files without ACLs?

From: Andreas Gruenbacher <[email-masked]>
Date: Wed, 26 Jul 2006 12:25:46 +0200

I am wondering what the best strategy is for representing files on POSIX that 
don't have an actual NFSv4 ACL, and access to which is only controlled by the 
file mode permission bits. This is only relevant on a server that supports 
ACLs on at least some files as indicated by the ACL4_SUPPORT_ALLOW_ACL and 
ACL4_SUPPORT_DENY_ACL flags in the aclsupport attribute: in that case, the 
mode attribute sufficiently describes the access permissions.

The two strategies I can imagine are to somehow indicate to the client that a 
particular file "has no ACL", or to make up an ACL which represents the file 
mode. This case is different from an empty (zero-entry) ACL, for which 
RFC3530 defines that the result is undefined. (I interpret undefined as 
either always denied or always allowed, rather than defined by the mask 
attribute).

My interpretation of the definition of the GETATTR is that when the server 
indicates ACL support it must return ACLs for all files, and it's illegal to 
not include an ACL in the return value of GETATTR if the client requests the 
ACL. Is this correct? In that case, we would definitely have to make up ACLs 
from the mode attribute.

Thanks,
Andreas

-- 
Andreas Gruenbacher <[email-masked]>
Novell / SUSE Labs

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

---

From: "J. Bruce Fields" <[email-masked]>
Date: Wed, 26 Jul 2006 16:50:48 -0400

> either always denied or always allowed, rather than defined by the mask 

It could mean whatever you want, but I think every current
implementation probably takes that to mean a deny, and the current 4.1
draft says it's a deny.  (Assuming it's just a case of reaching the end
of the ACL while still having permission bits neither allowed nor
denied.)

> ACL. Is this correct?

I believe that's correct.

--b.

---

From: Andreas Gruenbacher <[email-masked]>
Date: Thu, 27 Jul 2006 03:30:54 +0200

On Wednesday, 26. July 2006 22:50, J. Bruce Fields wrote:
> > The two strategies I can imagine are to somehow indicate to the client
> > that a particular file "has no ACL", or to make up an ACL which
> > represents the file mode. This case is different from an empty
> > (zero-entry) ACL, for which RFC3530 defines that the result is undefined.
> > (I interpret undefined as either always denied or always allowed, rather
> > than defined by the mask attribute).
>

Ack. My point was that we do not want to have it that in case of an empty ACL, 
the mask attribute must be considered to determine access.

Andreas