[ACL-Devel] archiving acls: tar and cpio

[Michael Ju. Tokarev]

Andreas Gruenbacher wrote:
> 
> On Sat, 14 Oct 2000, Michael Ju. Tokarev wrote:
> 
[]
> >
> >   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
> >
[]
> 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'.
...
> 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.

BTW, Andreas -- did you noticied that I cross-posted
my mail to both acl-devel and posix1e lists?
(and your answer was sent to both lists also ;) ).

Yes, we're not allowed to use this `security.*'.
I'm still not comfortable to write to austin group
maillist -- maybe we should consult/inform them also?


[]
> > 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.

Partially agree.  I don't see _real_ trouble here --
no ever dumb implementation can write that acl data to
directory...  Yes, for dumb writers this can cause troubles.
But that's for really dumb ones that ever does not see
difference between regular file and directory (i.e. for ones
that ignored file type value).  Moreover, pax format defines
extended header the same way -- extended header comes as
"file entry" before real file to that it belongs for dumb
archiver.  I consider this the best method available
(contents of this special header "file" is irrelevant
here for now).  At least it is better than storing all
extended attrs in one single file with special name like
used on Irix (thanks Casey Schaufler for pointing this),
from different points of view.

[]
> >
> >  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.

Ugh.  1003.1e draft 17 refers only to format used by [gs]etfacl
utilities.  That utilities are mostly for humans, not for archivers,
but I agree that this format can be used inside an archive.

  How about this two (separator does not matter):
  user:oracle:23:rwx,group:dba:50:r-x,...
  user:oracle#23:rwx,group:dba#50:r-x,...
  user:#23:rwx,...  -- this one if there is no username for uid 23
Interesting that solaris can use both numeric or symbolic "names"
(that can leads to conflicts -- what if we have real "user"
named "1000" -- sometime ago we had have this).  If there
is no name corresonded to some id used in fs, solaris
will use that id (in dec) instead of name.
(BTW I use solaris only as a reference here, as it is the
only system available for me now that have support for acls;
solaris isn't used here anymore (we use linux), so _for me_
compatibility with it isn't really important; but I think
that gnu pax should support solaris formats anyway).

About separator.  Austin group draft (I already quoted it):

 [...]
 pax Extended Header

 A pax extended header contains values that are not appropriate
 for the ustar header block because of limitations in that
 format [...].  The values in an extended header add attributes
 to the following file [...] or override values in the following
 header block(s), as indicated in the following list of keywords.

 An extended header shall consists of one or more records, each
 constructed as follows:

   "%d %s=%s\n", <length>, <keyword>, <value>
 [...]

There is no limitations defined for <value> here.  Also, alredy
defined <keyword> is `comment' that can contain any octets
(including newline).  So it's ok to use any separator here.
Moreover, newline can be preferred, as comma can (?) be used
in usernames (! ;)).   But I recall that gnu utils should support
solaris (and others) format also.

[]
> 
> 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.

What does you mean here -- What is "implementing"? -- there are already
two pax implementations available (among others) -- them are GNU
paxutils and also some variant probably from *BSD:

  /*      $OpenBSD: pax.c,v 1.11 1997/09/01 18:29:58 deraadt Exp
$        */
  /*      $NetBSD: pax.c,v 1.5 1996/03/26 23:54:20 mrg Exp $      */

  /*-
   * Copyright (c) 1992 Keith Muller.
   * Copyright (c) 1992, 1993
   *      The Regents of the University of California.  All rights
reserved.
   *
   * This code is derived from software contributed to Berkeley by
   * Keith Muller of the University of California, San Diego.

(I found this on standard redhat installation as pax-1.5...rpm)
(There is also AT&T implementation in `ast' package, with strange
licence that I don't understand, and with many strange non-standard
features e.g. able to do "incremental backups" storing only deltas
for each changed file).

Both already have full support for extended headers -- the only
thing missed here is a support for this particular keyword(s)
in extended header.

> 
> 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.

For "plain" tar/cpio acls already can be stored (solaris, others).
Both this formats can be considered "dead" now (while tar is the
only format widely used now) -- to be replaced by pax.  There is
already one separate question exists -- how to store acl data
(format of acl entries) that is independed on how any extended
attributes can be stored (e.g. "extended header" itself and format
of `security.acl' or `LINUX.acl' <value>).  Plain tar/cpio probably
will not support any other EAs except those them already supported
via vendor extentions.

Ok, I'll look to situation with pax.  Should this be considered my
mistake that I didn't contacted with Paul Eggert? :)

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