Copying EAs and ACLs

[jw schultz]

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.

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.

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

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




-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw at pegasys.ws

		Remember Cernan and Schmitt