[ACL-Devel] archiving acls: tar and cpio

[Andreas Gruenbacher]

On Sat, 14 Oct 2000, Michael Ju. Tokarev wrote:

> After reading of some docs (I finally got Austin group
> drafts -- thanks Andreas!), and reverse-ingeneering of
> Solaris formats, I have the following:

Michael, thanks very much for that info.

> The best way to do this is to use/extend pax utility,
> based on Austing group draft.  BTW, I like the pax command
> line interface -- it is simpler than of the tar and cpio,
> and have very powerful features.  Austin group already defined
> a common way of extending `pax' format (based on `ustar') --
> by using extended header (`g' and `e' typeflags in ustar
> header).  That headers should contain a series of attribute
> definitions like this:
>   len keyword=value\n
> where len is a full length of the `keyword=value\n',
> keyword is an attribute name and value is it's value.
> Currently there are some keywords already defined, such
> as `comment', `gname' etc.   There are already defined keyword
> _prefix_ to deal with our needs here:
> 
>   security.any  The keywords prefixed by ``security.'' are
>    reserved for future standartization.
> 
> Based on this, ACLs can be stored like this:
> 
>   nnn security.acl=user::rwx,...,group:staff:r--\n
> 
> The problems with this pax format are:
> 
>   o currently the format of the acl `value' is not
>    defined, and even keyword for it.
>   o there are no pax utility available in widespread
>    use in gnu/linux systems.
>   o there are no other systems exists that supports
>    this non-existed format.  For systems that have
>    pax implementation, our `security.acl' attribute
>    will be simply ignored.

We are not allowed to define security.* attributes for pax. Vendor
extensions should be `VENDOR.*'. Also, we will need two attributes for
ACLs, like `LINUX.acl' and `LINUX.acl.default'.

> Most commonly used format now is `tar' (ustar) format,
> and gnu tar implementation.
> 
> I looked to implementation of solaris's tar and cpio
> utilities -- there is a possibility to use their format
> also in just "plain" tar/cpio, and be compatible at least
> with one existed system.  Here it comes:
> 
> Both utilitied uses common method of storing ACLs, and
> this method compatible with pax way of extending ustar
> archives and posix definitions for ustar and cpio.
> ACLs stored in a file of special type (stored in typeflag
> field in tar and mode field in cpio) just before actual
> file for that this ACLs defined.  This is how pax stores
> it's extended header.  Other fields in header are just the
> same as for following file itself except of size field.
> ACL data itself stored "in first file".
> This way, for "older" archivers that can try to extract
> this "pair" of files, original file will be extracted
> twice, first time with contents of ACLs and second with
> actual data.

This might leads to trouble if restoring directories/special files.

> Both tar and cpio shares common format for ACLs data.
> It defined as follows:
> 
>   <number>\0<acl data>\0
> 
> ("file" size is a size of this sequence including number
> and trailing zero).  <number> is an octal representation
> of count of acl entries with added 01000000 (I don't know
> what this value means -- may be version?).  For example,
> for ACL set with 8 entries <number> will be `1000010'.
> <acl data> is a text representation of acl entries,
> delimited by commas.  Example (split to two lines for
> readability):
> 
>  1000010\0user::rw-,user:root:r-x,user:oracle:rwx,group::\
>  r--,group:root:r-x,group:bin:rwx,mask::r--,other::r--,\0
> 
> (this has size 110 decimal -- from the first '1' to last
> '\0' inclusive).

What I'm missing here is a way to store both user/group id's and names. I
see this as important, especially when restoring after a disaster you
don't usually have the full user database when staring to restore.

There are a number of possible formats:

comma separated:
  ...,user:oracle=23:rwx,...

line separated:
  ...
  user:oracle:rwx\t#id:23\n
  ...

The comma separated format would be non-standard, while the line separated
format would be valid input to setfacl. Setfacl (or rather the library
functions used) could also be modified to understand the id's directly.
Both formats could be easily supported, but only the line oriented format
is backwards compatible to 1003.1e draft 17.

> [...]
>
> The format choosed by Solaris seemed to be good for me. And I see that
> this can be easily implemented inside both gnu tar and gnu cpio.
> 
> Now, I have a question... :) Archiving needs to be done just _now_.  
> There are already exists some format for archives.  New standard
> format isn't ready.  What we should do now?
> 
> Does someone (except me) interested in having some method of archiving
> files that will be incompatible with future formats (well, if gnu pax
> will not support e.g. solaris extensions)? This will be temporary and
> incomplete solution, but real one. Or maybe someone have better
> proposals?
> 
> BTW, the format I described here does not deal with other extended
> attributes at all.

Michael, what about implementing a very small subset of the pax extended
header format (no global extended headers, for example)? Compatibility
with Solaris concerning this doesn't seem worth much, as I would guess all
vendors (SGI, HP, Compaq) have their own incompatible format already.
Using the pax format would give us a decent chance of being compatible
with what will be in use in one year or two.

Right now you are concerned about backing up ACLs (I am, too). In maybe a
couple of months you may also be concerned about backing up filesystem
capabilities, and whatever makes it into the kernel that allows more
secure and usable systems.

I think a hack that doesn't support extended attributes isn't worth the
effort. That wouldn't be a big improvement over the current kludge for
backing up / restoring using the utilities. When starting to use anything
other than ACLs, you would essentially be back where you are right now.

I would then store ACLs as `LINUX.acl' and `LINUX.acl.default' attributes,
and all the other extended attributes as `LINUX.attr.*' or similar. Maybe
we can agree on a common format to be used for storing ACLs with the other
posix1e guys (<posix1e at cyrus.watson.org>), so we can at some point rename
`LINUX.acl' to `security.acl' etc.


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