Copying EAs and ACLs

[jw schultz]

On Mon, Mar 10, 2003 at 12:16:05PM +0100, Andreas Gruenbacher wrote:
> 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.

There is a significant mismatch between the goals of the
NFSv4 ACLs and the storage of POSIX ACLs.  The NFS ACLs
aren't even worth discussion.

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

Hogwash.  Unless you start adding all sorts of new access
bits and other cruft that changes the whole semantics of
permissions so they cease to match POSIX it just isn't going
to change that much.  The only way that would happen is if
it went into some committee (like POSIX was) without the
input of actual implementers.

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

Sure they are.  They are part of the NFSv4 standard which
was written before it became clear what was going to be
happening to ACLs in UNIX.  Most of the additional flags meet
real needs for a network filesystem.  They have little to do
with the needs of rsync.

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

I wouldn't.  There is absolutely no need for that.  Like it
or not rsync is POSIX-centric and for the foreseeable future
will remain so.

> How would you incorporate 
> non-numeric user/group identifiers such as CIFS SIDs, or NFSv4 identifiers 
> like user at other.domain.com?

POSIX ACLs don't have any support for such identifiers.
Rsync cannot support such identifiers anyway.  CIFS and NFS
are network file access protocols not physical filesystems.

> I'm sorry but a simple format like the one you 
> outlined is not general enough for future use.

Only if the future is to dramatically change the user
identification or permissions semantics and there is as yet
no portable syscall or library interface for that.

I mentioned a simple example format that completely fulfills
the semantic requirements of the POSIX ACLs as defined in
the POSIX draft and as described in the bestbits and XFS acl
documentation.  In fact my example actually exceeds the
POSIX requirements since type and perm can be expressed in 4
and 3 bits respectively.  Using a short for perm would allow
another 13 bits of permission flags, that might even be
enough for NFSv4.
	


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

		Remember Cernan and Schmitt