strictly POSIX (was Re: Samba ACL's and FreeBSD (fwd))

Robert Watson rwatson at FreeBSD.org
Tue Apr 10 16:02:09 GMT 2001


On Tue, 10 Apr 2001, Andreas Gruenbacher wrote:

> > Additionally, the Linux implementation assumes a bitmask-based
> > acl_perm_t.  From what I can see, the spec does not state this is
> > required. Should the caller be allowed to compare multiple permissions
> > (e.g. ACL_READ|ACL_EXECUTE) in this case?
> 
> It uses a bitmask, but that fact should not be exploited in portable
> applications. That's what draft 17 seems to imply at least.
> 
> I don't see the technical reason why permission sets are not just
> treated as bitmasks generally, though. That would simplify the whole
> library a lot.

Well, you can imagine implementations where the underlying storage medium
didn't use a bitmask to store the set of rights, rather, selected some
other representation, or retrieved them from an ACL service using RPC's or
the like.  Similarly, you could imagine that the implementation provided a
set of rights that exceeded the size of a native C type capable of being
used as a bitmask.  In these cases, the ACL_WRITE-style permission
constants might not be implemented as single bits, rather, as an index
into another array, or as a type in a TLV array or the like.  D17 attempts
not to make any assertions about the internal representation of ACLs, and
that's probably a good idea.  I'm fine with a "is this right present in
this entry" call, but would be tempted to avoid a "is this mask of rights
present in this entry", instead using "is this list of rights present in
this entry". 

Robert N M Watson             FreeBSD Core Team, TrustedBSD Project
robert at fledge.watson.org      NAI Labs, Safeport Network Services


To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message



More information about the posix1e mailing list