ACLs etc and backup tools

[Robert Watson]

On Sun, 8 Oct 2000, Michael Ju. Tokarev wrote:

> There is a trouble now exists with backing up the extended
> file attributes (including acls, macs etc) with common tools
> like tar/cpio/dump/etc in a portable way.  The only command
> that can be used for "backups" now is `cp' that can preserve
> at least acls (not to say about MACs here), but this isn't a
> backup (thus it is in quotes).  And I don't know about a
> BSD implementation of cp -- if it can deal with acls or not.

Right now there are patches available to provide ACL support on FreeBSD
5.0-CURRENT, but the userland tools are largely not updated to deal with
ACLs as yet.  It's on the list of short term goals, however :-).

>    both numerically and symbolically.  So, the question --
>    what should be done with that systems that already have
>    _bad_ implementation of the subject?  Should we try to
>    be compatible with them, and if should, how?

The Solaris ACL API is not complaint with POSIX.1e, at least last time I
checked.  In fact, there are race conditions in most possible emulations
of POSIX.1e via Solaris, or vice versa, due to the combined access to
{access, default} ACLs in Solaris, vs. independent access in POSIX.1e.
This is similar to relative chmod races (get/set is non-atomic).

> ACL information itself represented by a series of ascii
> bytes contained text described ACL entries, similar to
> one used by getfacl utility.  E.g.
>   user:fred:10:rwx\ngroup:staff:20:r-x:\nmask:rwx\0\0\0
> (where \n is a linefeed, \0 is a pad byte)
> Here, 10 is a uid of user fred, 20 is a gid of group staff.
> Keywords "user", "group", "mask" etc probably can be abbreviated
> using one-letter "u", "g", "m" etc.  Rwx can be represented by
> a one-digit from 0 to 3 (using bitmasks similar to "main"
> standard file permissions).  Default entries can have keywords
> "defuser"/"defgroup"/etc or "U"/"G"/etc one-letter shortcuts.
> Linefeeds can be changed to \0.  -- this is all the variations,
> but the principle remains.
> 
> Can someone comment on all this?

The idea of storing both usernames and ids is nice, but it introduces the
possibility of new types of inconsistencies, rather than resolving them
all :-).  I.e., if you only had usernames and no matching username, then
you're not sure what to do before.  If you had uid's before, then you
might get the wrong user (what tar does currently).  If you have both,
what happens if the mapping conflicts?  Do you choose the id, or the
username?  My preference would be for holding only uid's/gid's, which is
compatible and fairly comprehensible to most administrators, rather than
introducing the possibility of confusion.  Possibly through in an optional
-n argument or something that writes out the archive with names instead of
numbers, allowing the recipient of the tarball (or whatever) to resolve
it.  Having only one entry in the field allows you to just use the
portable text ACL short form format from POSIX.1e, which resembles the
format you've described, except that it's already defined and portable
:-).

> There is almost no problems with implementing this (I mostly
> interested in tar for now, but cpio/dump/etc also should
> be extended this way) -- one or two evenings are enouth.
> But I'm not shure that introducing "home-grown" incompatible
> _format_ here is a good idea...

There's also a pile of other issues: a portably written tool should only
use portable APIs to retrieve EAs and ACLs.  If the ACL implementation
backs ACLs into EAs, then the two different access methods will return the
data: one in a portable format, and the other in a non-portable format.
Presumably only the portable format should be backed up--how do you know
which to back up? :-)

This comes back to the recurring issue of EA namespaces.  We seem to be
reaching some form of concensus that there should be a divided namespace.
Casey has proposed a multi-part division including an EA namespace for
kernel-only EAs, which would presumably not be backed up via the EA
interface, as well as a range of userland-accessible EA namespaces.
Presumably you would want to back up EAs stored by standard applications
and not available via another system API.

I've carefully avoided answering the question about the right existing
tar/cpio/whatever framework to use, as that's a "hard" question.  My
understanding is that the Austin group is defining extensions to Pax to
deal with extended attributes--presumably that would be the "right"
answer, but I haven't been following that work, so can't comment on it.

  Robert N M Watson 

robert at fledge.watson.org              http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37  ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services



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