[ACL-Devel] archiving acls: tar and cpio

[Andreas Gruenbacher]

On Mon, 16 Oct 2000, Robert Watson wrote:

> 
> So I don't have a whole lot of opinions on the matter of ACL backups, but
> do have a few preferences in the name of making it likely you can tar/pax
> a file on Linux, and untar/pax it on FreeBSD and have the results make
> sense :-).

That would be a really good thing.

> 1) The backup format should use the closest possible approximation to the
> POSIX.1e ACL text format that can satisfy its requirements.  I accept the
> argument that you may want to back up with both usernames and uids, and
> right now the ACL text format doesn't let you do that.  My preference on
> the alternative format would be an extension to the qualifier field, in
> or close to the manner described by someone already:
> 
>    user::rw,user:rwatson#1000:rw,group::r,mask::rw,other:r

So you think the '#' character is appropriate. I can live with that, but I
think another delimiter would be better. Right now, one can easily write a
parser that accepts both comma separated and multi-line ACL formats
automatically. If the '#' character is reused, that becomes pretty hard as
it introduces a comment in line oriented format. So I would prefer a
different delimiter, like '%' or whatever.

Robert, what's your opinion on this?

> As such, we should introduce a new acl_from_text() varient that allows the
> caller to specify precedence rules, etc.  acl_from_text() is already
> required to turn usernames into uid's, so there would be no new
> functionality dependencies.  You could imagine:
> 
>   acl_from_text_extended(const char *buf_p, int options)

That makes a lot of sense. In fact, I have implemented the reverse
operation in a similar way already: acl_to_any_text() takes a couple of
additional parameters, including a bit mask, with wich you can control
whether `#effective:' comments are generated, whether id's or names are
printed, etc. acl_to_text() is implemented as a special case.

> > Where options could be a bitmask or choice specifying the desired
> behavior, with 0 indicating to act identically to acl_from_text().  You
> could imagine options such as:
> 
>   ACL_FROM_TEXT_IDS_ONLY	# use numeric ids only, fail if none
>   ACL_FROM_TEXT_IDS_PREFER	# use numeric ids in preference to names
>   ACL_FROM_TEXT_NAMES_PREFER	# use names in preference to numeric ids
>   ACL_FROM_TEXT_NAMES_ONLY	# use names only, fail if none
>   ACL_FROM_TEXT_ONE_ONLY	# use whatever is there, but fail if
> 				# both exist
>   ACL_FROM_TEXT_FAIL_AMIGUOUS	# use whatever is there, but fail if
> 				# both and ambiguous
>
> Of the last two, I'd probably prefer ONE_ONLY to FAIL_AMBIGUOUS.  :-) 

The minimum I would require would be to use names whenever possible, and
to fall back to uid's if a name is not defined (like GNU tar, or
ACL_FROM_TEXT_NAMES_PREFER). Also, an option is required to explicitly
ignore names (say, ACL_FROM_TEXT_IDS_ONLY).

ACL_FROM_TEXT_IDS_PREFER is redundant if the ACL string contains id's
consistently, which they usually should. I would prefer not to implement
the other flags `just in case', and I'm not sure they are really needed.

> 2) Rules for interpreting ACLs and giving preference to ACL vs mode, both
> types of ACLs, etc, be well-defined.  For example, use vendor name
> posix1e, attribute names acl.{access,default}.

As I understand the specs, the `security.' prefix is reserved for ACLs and
similar objects. The names `security.acl.access' and
`security.acl.default' should be fine.

However, before using these names, I would like to hear the opinions of
others (particularely those who wrote the pax spec and those who wrote the
1003.1e/1003.2c specs).

> Given the presence of mode and ACL, use a fixed combining rule so as
> to get relevant features of both: suid bits, etc.  Well defined
> warning and failure modes: if default ACL exists for a directory, spit
> out a particular error, what to do if ACLs are stored in the archive
> but not supported on the target file system (warn and apply mode only,
> which should have appropriate mask-relationships with the ACL, etc.

A useful check would be to compare the file mode permission bits against
the ACL entries. I would give the ACL precedence in case of conflicts, on
filesystems that support them. On other filesystems, the file mode
permission bits might be a better choice.

> Deciding these things in advance means we're much more likely to be able
> to get some minimum level of portability :-).  Extending the from_text api
> means some hope of consistent parsing and precedence rules.

This involves at least the following:
 - function name and interface, required flags, etc.
 - which extended attribute names to use in the pax archive
 - ACL format to be used
 - rules how to combine the file mode permission bits with the ACL

Thanks,
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