Relative vs. absolute ACLs, and necessity for '-' when printing

[Andreas Gruenbacher]

On Sun, 17 Dec 2000, Robert Watson wrote:

> 
> Two quickies:
> 
> 1) The POSIX.2c setfacl spec refers to "absolute" and "relative" ACLs.  In
> permission-land, the difference has to with the use of an operator ('-',
> '+') rather than specification of a mode directly.  In ACLs, I would guess
> it involves invidual entries in the ACL using operators rather than
> absolutely specifying the rights, but I was unable to find this definition
> in .1e or .2c  Could someone point me in the right direction?

I guess the "relative" ACL is a rest of a feature that was previously in
the specs. My own implementation of setfacl actually includes relative ACL
entries for the -m and -M operations, but I consider this a failed
experiment. I've never actually needed relative ACL specifications; the
semantics are also somewhat quirky. To make this feature really useful,
tag type and qualifier wildcards would be important. If I had to start
over, I wouldn't include this feature again.

Here is what I've implemented, anyway:

  Relative ACL entries are of the form `user:uid:{+|^}perms' etc.;
  `+' meaning addition of permissions, `^' meaning subtraction of
  permissions. Relative operations never create new ACL entries. So
  `setfacl -m u:joe:^w ...' would remove the write permission from all ACL
  entries for user Joe. This doesn't imply Joe doesn't have write access
  afterwards, though.

> 2) The .2c getfacl specification states that a given right letter ("w",
> for example) "may" be replaced by a "-" if the right is not present.  As
> such, in my first implementation, I simply listed rights present when
> using acl_to_text(), such that I got "...:rw", or "...:w" or the like.

I understood the specs to be interpreted like this: Each defined
permission is allotted a character. If that permission is present, the
character is the assigned letter. Otherwise, it is '-'. So without
extensions, the permissions are always three characters wide. To me the
advantage of this approach is that ACLs become somewhat easier to read.

> It strikes me that setfacl is a fairly unfortunate and over-burdened
> set of functionality, and that it's also rather hard to implement
> given the ACL editing library.

Yes. With the ACL editing library alone setfacl is awful to implement.

> Earlier on the list, Andreas and I discussed an
> acl_from_text_with_flags() type of call that accepted a flags field
> indicating the types of conversions to perform to merge a starting ACL
> with a modifying ("relative"?) ACL so as to better support setfacl.  
> Given that my implementation of setfacl is fairly incomplete, I don't
> have a sense of the best supporting calls to use here, and any
> guidance would be appreciated.  :-)

I had a flag in mind to specify whether to use numeric or textual id's (or
both) and similar things. This would be useful for both acl_from_text()
and as acl_to_text().

Really for setfacl you don't need a relative ACL but a sequence of
operations to apply to an ACL. Think about what `setfacl -b -m u:joe:rw
file1 file2' should do to the ACLs of file1 and file2...


Cheers,
Andreas.

------------------------------------------------------------------------
 Andreas Gruenbacher, a.gruenbacher at computer.org
 Contact information: http://www.bestbits.at/~ag/

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