ACLs etc and backup tools

[Michael Ju. Tokarev]

Hello, folks.

I'm new to this list.
And want to ask a question and/or start the discussion... :)

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.

My primary interest is in Linux (EA/ACL for linux is available
at http://acl.bestbits.at/).  But tools used for archiving
should be portable, hence this my letter here.

Posix 2c draft mentioned cpio and tar, but concluded that
formats used by those archivers are not sutable for storing
additional security attributes.  Also, HP/UX implementation
(as I was able to find info about -- in man pages dated 1996
or so) also has not included acl support in their tar/cpio
archives.  I can't agree with this -- both formats _are_
extendable for this.  The only two (3, strictly speaking)
questions remains.

  1) what format should be used for storing that additional
   file attributes inside archives?  This is most important
   and difficult question (see below).

  2) is it ok to extend common format at all?  I.e. how existing
   tools should deal with new format?  For GNU tar, for example,
   it is not a problem -- it warns and ignores any unknown file
   "types" (and this is only way of storing extended attributes
   in tar -- by introducing new file "types" with "contents" of
   that attributes), but I don't know for other implementations.
   At least it is bad if some implementation will just fail to
   process archive if it encountered some unknown file type.

  2a) On some systems, f.e. on Solaris, there are already
   implementations of archiving EAs available.  I know about
   Solaris only -- it have support for both tar and cpio
   (tar file "type" for ACL is 'A').  But this particular
   implementation is weak -- f.e. tar stores only numeric
   ids for ACLs inside archive (without user/group _names_)
   while in ustar header file owner and group represented as
   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?

About format.  One interesting general question exists here --
should EAs be stored in a general way regardless on it's "type",
or there should be it's own format for each type of EA?
I.e. should we store ACLs and MACs and so on, or just EAs?
(I mean that EA, or Extended Attribute, is a general name for
any particular additional information about file, including,
but not limited to, ACLs, MACs, maybe mime type, etc).
Yes, when we speak about ACLs, there should be separate acls
entry inside archive, since ACLs should be stored in archive
in different format compared to one used in filesystem
(not including endianess/sizeof(int) issues) -- in _both_
numeric and symbolic forms (while it is sufficient to store
'em as numeric uids inside filesystem).  So, probably format
should include one entry type for each type of EA stored in
archive...

Ok, some proposals.  For tar as a start.

In tar header, use dedicated new file "type", say "A", to
store ACLs.  Name of a file should be the name of a "owner"
of that acl.  "File" length will be length of the following
blocks where acls are stored.  ACL information ("A" header
and subsequent blocks) should be placed just after actual
file contents that them refer to, but this is not strict
requirement.  But acl information MUST be placed _after_
actual file contents.
File type byte is a byte in header in offcet 156.
Currently defined and recognized by GNU tar types
(as of version 1.3.17):

 #define REGTYPE  '0'            /* regular file */
 #define AREGTYPE '\0'           /* regular file */
 #define LNKTYPE  '1'            /* link */
 #define SYMTYPE  '2'            /* reserved */
 #define CHRTYPE  '3'            /* character special */
 #define BLKTYPE  '4'            /* block special */
 #define DIRTYPE  '5'            /* directory */
 #define FIFOTYPE '6'            /* FIFO special */
 #define CONTTYPE '7'            /* reserved */

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?

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

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