[ACL-Devel] tar file format?

[Andreas Gruenbacher]

Michael Tokarev wrote:
> 
> Linda Walsh wrote:
> >
> > Andreas Gruenbacher wrote:
> > >
> > > Michael Tokarev wrote:
> > > >
> > > > Does anybody knows how the acl entries should be represented
> > > > in tar?
> > >
> []
> >         Under Irix there is a -M option that is supposed to store all the
> > CAP, MAC and ACL information.  It dumps it to 1 specific file, say "/tmp/.foo".
> > So if you looked at the tar, you'd find a copy of /tmp/.foo for each file on the
> > tape.  When it is unpacked, tar should read the /tmp/.foo after it restores each
> > file and set the ATTR block up accordingly.  If you unpacked with a normal
> > version of tar that doesn't know about ATTR's, it would just write over /tmp/.foo
> > a bunch of times needlessly.  I suppose at the end of an archive an empty /tmp/.foo
> > should be written to zero out the last remaining ATTR block info.
> 
> Hm. This seemed to be very bad idea. Acls, CAP, MAC etc should be _in_ tar archive,
> so this info can be safely backed up and restored (possible in different machine)
> without any addition files.  What is tar? -- it is just a collection of files (and
> attributes) that resides in one (!) another archive file, and this another file is
> good to backups, transfers etc etc.  _One_ file.  One possible solution is to merge
> that /tmp/.foo into resulting tar archive, but this is not perfect (as tar format
> stores all related file info with file, so that it will not need to seek inside
> archive to restore all file info (esp. on tapes), and even if so, /tmp/.foo will
> become an implementation detail).

Actually, the /tmp/.foo file is in the archive. AFAIK it's just a magic filename
the Irix version recognizes as such. Ordinary tars , and thus just generate a
file in the /tmp directory. Which is also quite ugly.

Another choice would be to use regular file records with identical filename for
both, and recognize the difference by another special value (such as a date
stamp in 1970). This would work perfectly for regular files, but would cause
trouble for directories. We would need to prepend these special blocks for
files, but append them to directories in tar archives so that older tars don't
puke. Yuck!

> As I found at solaris, there is just a special "file" type defined.
> Among with (cut&paste from tar.h):
> [...]
> there is additional "ACLTYPE" (but that is not defined in header), e.g.
> #define ACLTYPE         'A'
> Archived file with acls looks like:
> 
>   0 (regtype) block with name, owner, group, {amc}time, unix perms etc (512 bytes)
>   some blocks with file data
>   A (acltype) block with name (again!) and some info I don't know of (512 bytes)
>   some blocks with acl info (in some strange format, with garbage at the end)
> 
> With this, tar that doesn't knows about ACL (as gnu tar) just prints "unknown
> file type `A'" and skips remainding blocks.

An additional type seems a better solution to me. But the Solaris approach is
too simplistic. We need to store arbitrary extended file attributes as
name/value pairs in this file, not just ACLs. This includes ACLs, ..., but also
ext2 file attributes and user-defined stuff.

Also, it's not portable to use binary representations. We can use the textual
representations defined in 1003.1e.

Also, I don't know how tars other than GNU tar react on file types they don't
know. If they abort, they won't be able to read such archives. I think that
really the tars ought to be fixed.

As a workaround, a simple tar filter that discards unknown file types should be
easy to write.


Andreas

------------------------------------------------------------------------
 Andreas Gruenbacher, a.gruenbacher@computer.org
 Contact information: http://www.bestbits.at/~ag/
-------------------------------------------------------------------------
Linux ACL Developers List ---  http://acl.bestbits.at/acl-devel/

To unsubscribe, send a message with `unsubscribe acl-devel'
in the message body to majordomo@bestbits.at.
-------------------------------------------------------------------------