[ACL-Devel] archiving acls: tar and cpio

[Michael Ju. Tokarev]

Andreas Gruenbacher wrote:
> 
> On Mon, 16 Oct 2000, Robert Watson wrote:
> 
[]
> > or close to the manner described by someone already:
> >
> >    user::rw,user:rwatson#1000:rw,group::r,mask::rw,other:r
> 
> So you think the '#' character is appropriate. I can live with that, but I
> think another delimiter would be better. Right now, one can easily write a
> parser that accepts both comma separated and multi-line ACL formats
> automatically. If the '#' character is reused, that becomes pretty hard as
> it introduces a comment in line oriented format. So I would prefer a
> different delimiter, like '%' or whatever.

What I really suggested was this:

  user:::rw,user:rwatson:1000:rw,group:::r,mask:::rw,other::r

I.e. to have one more field for the id -- instead of
  type:grantee:perms
having
  type:grantee-name:grantee-id:perms

(Andreas, that extra colon was not an "in-field" delimiter but
"between-fields" delimiter).

If using # character, it is ok to place id at the end of entry,
like

  user::rw,user:rwatson:rw#1000,group::r,mask::rw,other:r

but with this, it can be

  user::rw,user:rwatson:rw#id:1000,group::r,mask::rw,other:r

(like in "... #effective:r-x")

[]
> 
> > As such, we should introduce a new acl_from_text() varient that allows the
> > caller to specify precedence rules, etc.  acl_from_text() is already
> > required to turn usernames into uid's, so there would be no new
> > functionality dependencies.  You could imagine:
> >
> >   acl_from_text_extended(const char *buf_p, int options)
> 

Why archiver can not have it's own variant of acl_to_text() ?
Is this just because of acl_t is opaque to application?
Where it _requires_ to be opaque?
Again, refering to solaris, all acl_t internals visible to
application, and definition is quite the same as in-kernel
structures used in linux, like
 {
  int type;
  some_int id;
  int perms;
 }
(I don't remember actual type of `some_int').
If this structure is visible, it is ok and easy for app
to implement it's own conversion function.  Moreover, if
there are some bits in eg perms inside archive that can't
be understand by app (like proposed in linux implementation
`add' permission, having user:mjt:rwxa), app will have more
control on what to do instead of just printing something
like `can't set acl', as returned by text_to_acl() "from os".

> > > Where options could be a bitmask or choice specifying the desired
> > behavior, with 0 indicating to act identically to acl_from_text().  You
> > could imagine options such as:
> >
> >   ACL_FROM_TEXT_IDS_ONLY      # use numeric ids only, fail if none
> >   ACL_FROM_TEXT_IDS_PREFER    # use numeric ids in preference to names
> >   ACL_FROM_TEXT_NAMES_PREFER  # use names in preference to numeric ids
> >   ACL_FROM_TEXT_NAMES_ONLY    # use names only, fail if none
> >   ACL_FROM_TEXT_ONE_ONLY      # use whatever is there, but fail if
> >                               # both exist
> >   ACL_FROM_TEXT_FAIL_AMIGUOUS # use whatever is there, but fail if
> >                               # both and ambiguous
> >
> > Of the last two, I'd probably prefer ONE_ONLY to FAIL_AMBIGUOUS.  :-)
> 
> The minimum I would require would be to use names whenever possible, and
> to fall back to uid's if a name is not defined (like GNU tar, or
> ACL_FROM_TEXT_NAMES_PREFER). Also, an option is required to explicitly
> ignore names (say, ACL_FROM_TEXT_IDS_ONLY).
> 
> ACL_FROM_TEXT_IDS_PREFER is redundant if the ACL string contains id's
> consistently, which they usually should. I would prefer not to implement
> the other flags `just in case', and I'm not sure they are really needed.
> 
> > 2) Rules for interpreting ACLs and giving preference to ACL vs mode, both
> > types of ACLs, etc, be well-defined.  For example, use vendor name
> > posix1e, attribute names acl.{access,default}.
>
> As I understand the specs, the `security.' prefix is reserved for ACLs and
> similar objects. The names `security.acl.access' and
> `security.acl.default' should be fine.
> 

Still don't understand why we need _two_ of them.  What's wrong with

  user:mjt:rwx,
  group:staff:rwx,
  mask:rwx,
  other:rwx,
  defuser:mjt:rwx,
  defgroup:staff:rwx,
  defother:rwx,
  etc (field count in each line does not matter here)

Also, exactly this way solaris's cpio/tar stores defacls.
(As I see from examination of raw filesystem blocks, solaris
stores both in one array, but I'm not shure about this, as
this is not an easy task to guess where numeric acls are
stored.  I tried to find binary representation of the above
structure with known type, id and perms on my disk).

(not strictly related but still -- it is ok to abbreviate
keywords to just one letter, having ugmo for acl and UGMO
(in uppercase) for default acls)

> However, before using these names, I would like to hear the opinions of
> others (particularely those who wrote the pax spec and those who wrote the
> 1003.1e/1003.2c specs).
> 
> > Given the presence of mode and ACL, use a fixed combining rule so as
> > to get relevant features of both: suid bits, etc.  Well defined
> > warning and failure modes: if default ACL exists for a directory, spit
> > out a particular error, what to do if ACLs are stored in the archive
> > but not supported on the target file system (warn and apply mode only,
> > which should have appropriate mask-relationships with the ACL, etc.
> 
> A useful check would be to compare the file mode permission bits against
> the ACL entries. I would give the ACL precedence in case of conflicts, on
> filesystems that support them. On other filesystems, the file mode
> permission bits might be a better choice.

Again for this to work app needs to either parse acls on its own or
to have access to contents of acl_t type.

Regards,
 Michael.

P.S.  Noone of tar/cpio/dump authors replied to my
requests/questions/proposals yet, dump-devel list is
also quiet.  This seemed to be funny: people can't
just use acls (e.g) because there are no support
for them in basic utils, but to made this support
people needs to use acls...  Like kitchen/eggs
problem... :)
To Unsubscribe: send mail to majordomo at cyrus.watson.org
with "unsubscribe posix1e" in the body of the message