Odd ACL question

[Tim Kientzle]

On Sat, 7 Feb 2004, Tim Kientzle wrote:
>Joerg Schilling's "star" archives ACLs as follows:
>
>"user::rwx,group::r--,group:mail:rw-:6,mask::rw-,other::r--"
>
>Note the "group:mail:rw-:6" entry that contains a fourth
>field with the uid/gid number. ...
>
>Question:  Is this a useful extension?

Harti Brandt responded:
> It definitely is. Joerg and I had several hours of talk on this issue.
> If you, for example, restore on a system that usually gets its passwd from
> YP or LDAP and you don't have it available ...

Ah.  That's the example I needed.  Now to figure out how to implement
such functionality; hacking the acl library functions may
not be the best approach, but I'm equally dismayed by the prospect
of duplicating the acl library functions in my code.  ;-(

> As far as I know there are options to star that let you select the exact
> behaviour in these cases.

This is one difference between 'star' and my work:  'star' offers
a great deal of control over the archiving/dearchiving
process; my work tries to remove the need for such control
by using intelligent algorithms.  For example, bsdtar/libarchive
doesn't require you to specify the compression when reading archives;
it determines it automatically.

In this case, I'm considering:
   * If the username exists, use that.
   * If the username does not exist and the UID is not already in
       use, issue a warning and use the UID.
   * If the username exists and the UID conflicts with the local
       system, ???

This last case is the tough one.  My temptation:  map it to
an unused UID, issue a warning about the remap, and keep going.

There are certainly rare cases where manual control is
needed.  That's why I'm pleased that 'star' is available
in ports.  ;-)

Tim Kientzle