Copying EAs and ACLs

[Andreas Gruenbacher]

On Monday 10 March 2003 11:45, jw schultz wrote:
> On Mon, Mar 10, 2003 at 10:18:13AM +0100, Andreas Gruenbacher wrote:
> > On Monday 10 March 2003 08:20, jw schultz wrote:
> > > On Sun, Mar 09, 2003 at 10:31:16PM -0800, Ben Escoto wrote:
> > > > Also there may be
> > > > no point if the getf[attr/acl] format is likely to change soon.
> > >
> > > I don't see any sign of the formats changing.  I only see
> > > two changes as probable.  One would be specifying either the
> > > acl_t type or the format of the "contiguous, persistent data
> > > item, the format of which is unspecified."  of the
> > > acl_copy_ext() and acl_copy_int() functions.
> >
> > I recommend not to use the _ext() functions. There is no definition of
> > the format at all, so it may not even be portable between two systems
> > with different endianness, let alone different OS'es. I would use either
> > the NFSv4 format, or else the acl_to_text() format.
>
> That is exactly one of my gripes with the ACL libs.  I
> cannot see any point to the _ext functions.   There is no
> format that anyone seems is willing to stand behind except the
> hideous text formats.  If the acl_t is the binary format why
> aren't its members documented.  Maybe you can tell the world
> why there is no library routine that returns a documented
> binary format?  I don't ask that it necessarily be all that
> portable.  Only that it be documented so a translation to
> portable without parsing text strings would be reasonable.
> Using strings to represent numeric user and group ids is
> absurd.

Even if IDs were transfered in binary form, the most portable way of setting 
ACLs would be via acl_from_text() and acl_set_file(). (There are  similar 
functions available on Solaris.) I don't think the size of ACLs is a 
significant problem, even in text form. But I would even recommend using the 
NFSv4 format for POSIX ACLs too.

> Look at the stat(2) manpage, it documents the structure it
> returns.  The definition of the various datatypes will vary
> according to the platform but that doesn't keep us from
> using it.  A definition of the members of acl_t would go a
> long way if it could be counted on. Lacking that adding
> acl_to_bin() and acl_from_bin() with a documented format
> to the libs would do.

ACLs are more complicated that struct stat. A flexible enough binary format 
would inevitably be a dynamic data structure, which would eventually become 
too unflexible.

> I really would prefer not to hack around the libs with
> version dependent stuff.  In fact reading through the libs
> reminds me of the obfuscated c contest.  That stuff needs a
> rewrite badly.

The 1003.1e drafts tried to define an object oriented interface on top of C. 
Also, the specification of the acl_* functions defines some semantics that 
are difficult to adhere to in a straightforward implementation. This is why 
the library has lots of warts.

You are invited to invent something better, of course :)

> The NFSv4 format is overloaded with flags that don't apply
> to storage but unnecessarily complicate going back to POSIX.
> In short they bloat the data.

For POSIX ACLs only a subset of flags would be needed. The NFSv4 format simply 
seems more future proof than an ad-hoc rsync format. I believe that NFSv4 
ACLs are here to stay.

> I would love it if i could get a format like:
>
> 	struct ace {
> 		unsigned char	type;
> 		unsigned short	perm;
> 		uid_t		id;
> 	};
> 	stuct acl {
> 		int		count;
> 		struct ace	ace[];
> 	};
>
> or even an array of struct ace where a NULL entry terminates.
>
> and tupe is testable for one of
> ACL_USER_OBJ,
> ACL_GROUP_OBJ,
> ACL_OTHER,
> ACL_USER,
> ACL_GROUP,
> or
> ACL_MASK
> and for
> ACL_DEFAULT

How would you extend the set of permissions? How would you incorporate 
non-numeric user/group identifiers such as CIFS SIDs, or NFSv4 identifiers 
like user at other.domain.com? I'm sorry but a simple format like the one you 
outlined is not general enough for future use.

Cheers,
Andreas.