ACLs etc and backup tools

[Michael Ju. Tokarev]

Robert Watson wrote:
> 
> On Sun, 8 Oct 2000, Michael Ju. Tokarev wrote:
> 
> >    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).

The Solaris API isn't concerned here.  My only goal here is
to define/understand the archive format to be used for EAs/ACLs,
not particular kernel/api implementation.  That's not an issue
here, while e.g. gnu tar can have a workarounds for buggy solaris
implementation (again, this is another story, not related to
formats).

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

Tar (ustar) already has this "confusion", and this one introduced
having in mind something useful.  The rule is simple: if a system
has this username, then use it (ignore the uid completely).  But
if not, then warn and have two choices: use stored uid (preffered)
or just current process uid (probably not an option for acls but
can be used for file owner).  (The same is for group/gid).
This way one not need to have equal uids/gids for all users/groups
on all systems.  And this was the cause of introducing owner/group
names in ustar format.

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

And does not includes numeric [ug]ids.

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

Again, for now, this isn't an _implementation_ issue that I'm talking
about (this one will be next) but a _format_ issue.

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

Ok, that was also my mind...  I thought that there should be separate
format(s) for "well-known" EAs (separate ACL entries for example) but
_may_ be format for some other sort of EA that is system-dependent
(e.g. "mime content-type" EA if such a beast will be used/useful at
all).

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

The "rights" question was already "answered" by some vendors, e.g.
Sun with Solaris (both Solaris tar and cpio has ability to store ACLs
(in some buggy way)) (and this was a bad news, as I was forced to use
solaris's tar instead of gnu one when I worked on solaris).

Unfortunately, Austin group (I know of it) uses strange politics about
it's drafts/works -- I was unable to find any pointers to at least
current work status...  Probably contacting them is a right way,
but I can't do that -- they require (as I understand) to pay a money
to see what's they doing -- _very_ strange position (but adopted by
other "standard" organizations, say, IEEE from that posix1e draft
comes).   And also, as I hear, them are far away from having something
complete, and the issues that I interested in currently (namely,
extentions for "pax" (btw, there is no such thing "pax format" -- pax
uses cpio and tar formats)) are near the end of a TODO list.
But systems that implements at least ACLs badly needed an ability to
backup/transfer files with that attributes.  And tar (way, pax, cpio --
name does not matter here) and [ufs]dump/[ufs]restore are the minimum
set of utilities (not counting trivial cp/mv/ls/[sg]etfacl/etc).

What I wanted at least is a way.  It's a pain to introduce "our own"
tools/formats for this, and be incompatible when things will (if at
all) be standartized.  I expect the same problems with OpenBSD when
users will start to use new abilities (them are very useful, really,
and the abcence of acls on linux forces me to use solaris for a long
time) and there is no tools to deal with them.  And I really don't
know what to do next except of adopting my format for myself...
Can we agree on some way and use some common formats for this while
someone (Austin et al) makes new standard on this?  Or we will wait
that standard?  I _really_ don't know what to do. :(

Btw, maybe ask/tell to gnu tar/paxutils maintainers also about this
question ?

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