Copying EAs and ACLs

2003-02-23 Thread Andreas Gruenbacher 
Hello,

I am the guy behind the ext2/ext3 patches for Extended Attributes and ACLs, 
and I've recently been asked about ACL support in rsync by Eric. Upon 
investigating I found that you have an ACL patch against rsync-2.5.5 [1]. I 
also found some other postings to [EMAIL PROTECTED] concerning rsync and 
ACLs [3].

Are there any plans for finalizing an integrating that rsync ACL patch?

I am posting my own thoughts on that topic with the hope to spur the 
discussion and accelerate the improvement of rsync in that direction.

ACLs are one part of supporting Extended Attributes in general, but they are 
important enough (and difficult enough to do right) to deserve special 
treatment. (I would like to see Extended Attributes in rsync too, of course.) 
Most UNIX systems support some variant of POSIX ACLs. Unfortunately the 
so-far-final draft 17 document the dissolved POSIX 1003.1e/2c working group 
has produced does not define how to deal with ACLs on a network.

Probably partly because POSIX ACLs didn't ever get standardized, the NFSv4 
protocol [4] among other things defines yet another kind of ACLs. NFSv4 ACLs 
are much more like Windows ACLs than POSIX draft 17 ACLs. What's more, the 
NFSv4 protocol not only defines the on-the-wire format to be used for ACLs, 
but also their semantics. This makes them problematic for POSIX ACLs. 
Nevertheless it seems that NFSv4 ACLs are here to stay.

So it seems to make sense to adapt them to POSIX ACLs, and to use them as the 
underlying transfer format for rsync. The SSH File Transfer Protocol 
 also 
specifies that scp is to use the NFSv4 ACL format, by the way.

Marius Aamodt Eriksen <[EMAIL PROTECTED]> has thought out a mapping between 
NFSv4 ACLs and POSIX ACLs [5]. While Marius's mapping most likely is 
semantically correct, I think that it is too complex to be useful 
practically. The main problem is to define a mapping for the POSIX ACL mask 
entry. I would recommend to transfer the ACL MASK entry as a proper ACL entry 
in NFSv4 ACLs with a who field of "MASK@", and to extend the permission 
evaluation mechanism of NFSv4 to take care for this additional entry.

At least as far as rsync is concerned, this proposed approach could be used 
without causing compatibility problems.

Another issue that has surely been considered for rsync is how to map between 
users/groups across different systems. On UNIX like systems this mapping can 
be done based on user/group IDs or names. If it is relevant for rsync to 
transfer both ID's and names between systems, this will be another problem 
with the NFSv4 ACL format.

(In star [6], an implementation of the PAX archive format defined in 
POSIX.1-2001, for storing ACLs, we have been using a text based format which 
is almost identical to what acl_to_text(3) produces, but with ID's added. The 
exact format used is documented in the file README.ACL inside the package. 
This approach is less powerful than NFSv4 ACLs, but good enough for POSIX ACL 
backups.)

Best regards,
Andreas Gruenbacher.


REFERENCES

[1] Buck Huppmann: patch: rsync-2.5.5: UNIX ACL support, 
.

[2] Gary Fernandez: [PATCH] change rsync to print warning if ACL detected, 
.

[3] General rsync ACL discussions, 
, 
.

[4] NFS version 4 Protocol, 
.

[5] Marius Aamodt Eriksen: Mapping Between NFSv4 and Posix Draft ACLs, 


[6] Jörg Schilling: Star, 


-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html

Re: Copying EAs and ACLs

2003-02-23 Thread jw schultz 
On Sun, Feb 23, 2003 at 01:13:56PM +0100, Andreas Gruenbacher wrote:
> Hello,
> 
> I am the guy behind the ext2/ext3 patches for Extended Attributes and ACLs, 
> and I've recently been asked about ACL support in rsync by Eric. Upon 
> investigating I found that you have an ACL patch against rsync-2.5.5 [1]. I 
> also found some other postings to [EMAIL PROTECTED] concerning rsync and 
> ACLs [3].
> 
> Are there any plans for finalizing an integrating that rsync ACL patch?
> 
> I am posting my own thoughts on that topic with the hope to spur the 
> discussion and accelerate the improvement of rsync in that direction.
> 
> ACLs are one part of supporting Extended Attributes in general, but they are 
> important enough (and difficult enough to do right) to deserve special 
> treatment. (I would like to see Extended Attributes in rsync too, of course.) 
> Most UNIX systems support some variant of POSIX ACLs. Unfortunately the 
> so-far-final draft 17 document the dissolved POSIX 1003.1e/2c working group 
> has produced does not define how to deal with ACLs on a network.
> 
> Probably partly because POSIX ACLs didn't ever get standardized, the NFSv4 
> protocol [4] among other things defines yet another kind of ACLs. NFSv4 ACLs 
> are much more like Windows ACLs than POSIX draft 17 ACLs. What's more, the 
> NFSv4 protocol not only defines the on-the-wire format to be used for ACLs, 
> but also their semantics. This makes them problematic for POSIX ACLs. 
> Nevertheless it seems that NFSv4 ACLs are here to stay.
> 
> So it seems to make sense to adapt them to POSIX ACLs, and to use them as the 
> underlying transfer format for rsync. The SSH File Transfer Protocol 
>  also 
> specifies that scp is to use the NFSv4 ACL format, by the way.
> 
> Marius Aamodt Eriksen <[EMAIL PROTECTED]> has thought out a mapping between 
> NFSv4 ACLs and POSIX ACLs [5]. While Marius's mapping most likely is 
> semantically correct, I think that it is too complex to be useful 
> practically. The main problem is to define a mapping for the POSIX ACL mask 
> entry. I would recommend to transfer the ACL MASK entry as a proper ACL entry 
> in NFSv4 ACLs with a who field of "MASK@", and to extend the permission 
> evaluation mechanism of NFSv4 to take care for this additional entry.
> 
> At least as far as rsync is concerned, this proposed approach could be used 
> without causing compatibility problems.
> 
> Another issue that has surely been considered for rsync is how to map between 
> users/groups across different systems. On UNIX like systems this mapping can 
> be done based on user/group IDs or names. If it is relevant for rsync to 
> transfer both ID's and names between systems, this will be another problem 
> with the NFSv4 ACL format.
> 
> (In star [6], an implementation of the PAX archive format defined in 
> POSIX.1-2001, for storing ACLs, we have been using a text based format which 
> is almost identical to what acl_to_text(3) produces, but with ID's added. The 
> exact format used is documented in the file README.ACL inside the package. 
> This approach is less powerful than NFSv4 ACLs, but good enough for POSIX ACL 
> backups.)
> 
> Best regards,
> Andreas Gruenbacher.
> 
> 
> REFERENCES
> 
> [1] Buck Huppmann: patch: rsync-2.5.5: UNIX ACL support, 
> .
Lots of code but no commentary.  I'm not too inclined to
wade through this until after an overview of what it does
has been given.

> [2] Gary Fernandez: [PATCH] change rsync to print warning if ACL detected, 
> .
This is mildly usefull.  Unfortunately it seems to be
Solaris 2+ specific.

> [3] General rsync ACL discussions, 
> , 
Nice wrapper for rsync to apply acls after syncing.

> .
Q: will rsync support ACLs?
A: Maybe the vendor tar does, you could sync a tar file.
A: no known plans for now, maybe in 3.0, heterogeneous
   support is difficult.
A: Not standardized and problems with out-of-band support.
A: Here's a wrapper to get around the deficiency.

> [4] NFS version 4 Protocol, 
> .
The whole protocol document in plain text.  Section 5 (pages
36-58) is the applicable one.  Much of this involves
negotiation of supported functionality and is further
overlaid by other stuff that is runtime oriented rather than
storage.  This is still worth the read and i will reading
it in greater depth later.

> [5] Marius Aamodt Eriksen: Mapping Between NFSv4 and Posix Draft ACLs, 
> 
Brief description of one-way mapping from POSIX to NFSv4
with brief descriptions of how each work.

> 
> [6] Jörg Schilling: Star, 
>

Re: Copying EAs and ACLs

2003-02-23 Thread jw schultz 
On Sun, Feb 23, 2003 at 01:13:56PM +0100, Andreas Gruenbacher wrote:
> Hello,
> 
> I am the guy behind the ext2/ext3 patches for Extended Attributes and ACLs, 

Thanks.

> and I've recently been asked about ACL support in rsync by Eric. Upon 
> investigating I found that you have an ACL patch against rsync-2.5.5 [1]. I 
> also found some other postings to [EMAIL PROTECTED] concerning rsync and 
> ACLs [3].
> 
> Are there any plans for finalizing an integrating that rsync ACL patch?

Not yet.  I'd like to see a decent overview of that patch's
approach before commenting on its chances.

> I am posting my own thoughts on that topic with the hope to spur the 
> discussion and accelerate the improvement of rsync in that direction.
> 
> ACLs are one part of supporting Extended Attributes in general, but they are 
> important enough (and difficult enough to do right) to deserve special 
> treatment. (I would like to see Extended Attributes in rsync too, of course.) 

As long as i have touched on the issue for rsync i have argued
for treating ACLs (file Access Control Lists) as a
special-case of EAs (file Extended Attributes).  I still
believe that is essential.  Aside from the blurred line
between ACLs and EAs in some filesystems there is the big
issue of inconsistent availability of support for these.

> Most UNIX systems support some variant of POSIX ACLs. Unfortunately the 
> so-far-final draft 17 document the dissolved POSIX 1003.1e/2c working group 
> has produced does not define how to deal with ACLs on a network.
> Probably partly because POSIX ACLs didn't ever get standardized, the NFSv4 
> protocol [4] among other things defines yet another kind of ACLs. NFSv4 ACLs 
> are much more like Windows ACLs than POSIX draft 17 ACLs. What's more, the 
> NFSv4 protocol not only defines the on-the-wire format to be used for ACLs, 
> but also their semantics. This makes them problematic for POSIX ACLs. 
> Nevertheless it seems that NFSv4 ACLs are here to stay.
> 
> So it seems to make sense to adapt them to POSIX ACLs, and to use them as the 
> underlying transfer format for rsync. The SSH File Transfer Protocol 
>  also 
> specifies that scp is to use the NFSv4 ACL format, by the way.

this document actually does a much better job of describing
NFSv4 ACLs than the NFS document.

So far POSIX ACLs seem to be what is being implemented at
the system and filesystem level.  In reality rsync doesn't
need to deal with the same issues as NFS.  Rsync's focus is
not in projecting the access rights semantics to determine
correct privileges but in preserving as much as possible the
original ACL data.


-- 

J.W. SchultzPegasystems Technologies
email address:  [EMAIL PROTECTED]

Remember Cernan and Schmitt
-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html

Re: Copying EAs and ACLs

2003-02-24 Thread jw schultz 
On Sun, Feb 23, 2003 at 01:13:56PM +0100, Andreas Gruenbacher wrote:
> Hello,
> 
> I am the guy behind the ext2/ext3 patches for Extended Attributes and ACLs, 
> and I've recently been asked about ACL support in rsync by Eric. Upon 
> investigating I found that you have an ACL patch against rsync-2.5.5 [1]. I 
> also found some other postings to [EMAIL PROTECTED] concerning rsync and 
> ACLs [3].

I'm on 2.4 and the only ACL docs i have are from XFS which
while consistant with POSIX i'm not using at the moment anyway.
getfacl (1)  - get file access control lists
setfacl (1)  - set file access control lists
chacl (1)- change the access control list of a file or directory
acl (5)  - Access Control Lists

Where can i find the system calls documented?  They don't
seem to be part of SUSv3 and Andreas Browne's latest
manpages have no ACL related manpages.

Thanks much.  I'm a bit concerned that onone else has spoken
up on this thread?
-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html

Re: Copying EAs and ACLs

2003-02-24 Thread Buck Huppmann 
On Sun, Feb 23, 2003 at 01:13:56PM +0100, Andreas Gruenbacher wrote:
> Hello,
> 
> I am the guy behind the ext2/ext3 patches for Extended Attributes and ACLs, 
> and I've recently been asked about ACL support in rsync by Eric. Upon 
> investigating I found that you have an ACL patch against rsync-2.5.5 [1]. I 
> also found some other postings to [EMAIL PROTECTED] concerning rsync and 
> ACLs [3].
> 
> Are there any plans for finalizing an integrating that rsync ACL patch?

i hope not

seriously, though, the work i did was--we hoped--something to tide us over
until something better came along. i have no illusions about or desire to
see its incorporation into the official source tree

i think that full-blown, general EA support is a laudable goal; my hope
was just to preserve--to the naive extent possible by stealing a lot of
other people's code and introducing as few of my own bugs as possible--
any additional permissions our folks are putting on their files so that
our rsync-ed ``mirrors'' of their stuff aren't any less secure than their
source images. in our case, simply preserving extended/discretionary ACLs
between our Solaris (and, it's hoped some day soon now, Linux) systems was
all we were looking for, and i'm content to live in ignorance of the more
arcane^H^H^H general issue of EA support, since it's not anything that
bears on security for our Solaris filesystems. (at least, i'm not aware of
any other attributes that have significance security-wise; which is to say
that i hope our users haven't figured out any yet)

nevertheless, it seems to me also that the NFSv4 approach is a bit verbose
and a bad enough fit for POSIX and Solaris/SysV ACLs, at least, that i
would think twice about dumping my patch in favor of an implementation
along those lines--at least if there weren't EAs that would benefit from
a fully generalized, all singing, all dancing implementation. (but then
again i am the sort who has trouble coping with the additional dimension-
ality of access control beyond the POSIX triple, think NT permissions are
a perplexing if exotic security nightmare, prefer single-letter options
to --gnu-style options, prefer man to info, coffee to latte etc.). and yet
i understand that somebody's going to figure out something cool to do with
extended attributes that users are going to want to have rsync preserve for
them and, in the future, it may be useless to transfer files at all with-
out such things (just think, filesystem cookies and referral paths--gag).
so maybe it's best to bite the bullet now, but i'm certainly not qualified
to do it. then again, maybe you wait and see if NFSv4 and supporting file-
systems force the issue, then you worry about it, just like seems to be the
present rsync development strategy . . . (whence, bad patches like mine
crop up to fill the void)

sorry to ramble cynically, but thanks for showing an interest in clearing
up the state of affairs and for your excellent work on ext2/ext3 EAs and
ACLs and libattr and libacl
-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html

Re: Copying EAs and ACLs

2003-02-28 Thread jw schultz 
On Mon, Feb 24, 2003 at 07:42:05PM -0800, jw schultz wrote:
> On Sun, Feb 23, 2003 at 01:13:56PM +0100, Andreas Gruenbacher wrote:
> > Hello,
> > 
> > I am the guy behind the ext2/ext3 patches for Extended Attributes and ACLs, 
> > and I've recently been asked about ACL support in rsync by Eric. Upon 
> > investigating I found that you have an ACL patch against rsync-2.5.5 [1]. I 
> > also found some other postings to [EMAIL PROTECTED] concerning rsync and 
> > ACLs [3].
> 
> I'm on 2.4 and the only ACL docs i have are from XFS which
> while consistant with POSIX i'm not using at the moment anyway.
> getfacl (1)  - get file access control lists
> setfacl (1)  - set file access control lists
> chacl (1)- change the access control list of a file or directory
> acl (5)  - Access Control Lists
> 
> Where can i find the system calls documented?  They don't
> seem to be part of SUSv3 and Andreas Browne's latest
> manpages have no ACL related manpages.

I've found the manpages and i see that they have been added
to the standard kernel set.

-- 

J.W. SchultzPegasystems Technologies
email address:  [EMAIL PROTECTED]

Remember Cernan and Schmitt
-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html

Re: Copying EAs and ACLs

2003-03-02 Thread jw schultz 

Access Control Lists (ACLs) and Extended Attributes (EA) are
an area i have seen for some time as something rsync will
need to address.  I've put a tighter focus on this issue for
the past week or so and have reached a few conclusions.

1. ACL and EA OS support is growing but not really there yet.

Most of the UNIX players have POSIX ACL support.
I have no data on UNIX EA support but as far as i
can tell it is mostly absent.

Linux does not have consistent support yet.  ACL
support is not part of mainstream production
kernels.  If you want it you have to either apply
patches or run a development kernel.  Some
distribution kernels are patched with ACL support
for one or more filesystems.

I know that XFS supports ACLs and EAs, later
versions of EXT2, EXT3 and JFS do also.  I'm not
entirely sure of the status of rieserfs.

2. Utility support is almost completely missing.

Not only does rsync not support ACLs and EAs yet but
neither does cpio, tar (with the exception of star)
nor most of the backup utilities.

3. Use lags support dramatically.

The vast majority of sites do not use either ACLs
nor EAs even when they can.  The lack of utility
support aggravates this.

Until support is ubiquitous across production-grade
OSs, filesystems and utilities the adoption of ACLs
and EAs will be delayed.

4. ACLs and EAs are a part of the future.

Users and admins are coming to linux and Unix with
the expectation of ACLs.  While intelligent use of
group IDs can more simply deal with _almost_ all
permissions issues, and by being simpler tend to be
more secure, many will prefer the quick fix ACLs
provide.

Some of the new security models i've seen are going
to require both ACLs and EAs.

The potential value of EAs in GUI environments
should not be underestimated.  Imagine file-manager
thumbnails and application icons that really are
attached to the file.

Even rsync may find good use for EAs.  I can
envision optional storing of blocksums as an
extended attribute.  A 64KB EA could support the
blocksums for a 127MB file using 4byte sums and 16KB
blocks.

Who knows what else the future might hold.  Once
people expect EA support.

Those applicable utilities that fail to support ACLs
and EAs will become irrelevant.

So while demand is currently low i believe that rsync will
need to support ACLs and EAs in the near future or it will
become little more than a limited download tool like ftp.
When that will be is an unknown but i think the release of
the Linux 2.6 kernel will be a major factor.  This means
that the widespread use of ACLs on the filesystems may well
begin in as little as one year if 2.6 comes out on schedule.

Where does that leave us?  What am i going to do about it?

Based on the level of comments on this and other threads
there is little demand presently for ACL or EA support in
the rsync user or developer base.  There are a few people
for whom this is a production issue today and a few like
myself who see it as a future issue that should be
anticipated.

I do not use ACLs or EAs currently.  I believe that support
for them should be added sooner rather than later and i
think that how that support is implemented is very
important.  I however do not use them at this time and
unless someone will pay me to do so i'm not going to set up
a lab or start slinging code to add that support.  Sorry but
this just isn't my itch yet.  While i care how it is done i
don't care enough yet to do it myself and build the test
apparatus. 

The remainder of this missive shall be a bit more technical.
Since i do care how they are implemented and have some
informed ideas in that direction it seems good to me to
relate those ideas.   If you like design documents think of
this as a start on a high-level one.  I don't generally care
for design documents but the design should be discussed
before such significant code is generated.  If you aren't
interested in such discussion, or don't care what i have to
say please move on instead of complaining.  I've broken this
down into several sections.

If you have comments to make please address one issue per
followup so they form separate sub-threads and only quote the
relevant text.  Unless there are comments i expect this will
be the last i'll discuss this issue for a while.

-- How have OSs implemented Access Control Lists --

In UNIX ACLs are implemented in various, sometimes
non-standard, ways.  For the most part it looks like they
are largely compatible with POSIX ACLs.

In Linux ACLs are implemented as an EA.  In order to
support ACLs on Linux and non-linux platforms we have
to treat them separately from the EAs.

Although NTFS s

Re: Copying EAs and ACLs

2003-03-02 Thread Max Bowsher 
jw schultz wrote:
> Although NTFS supports ACLs the cygwin environment does not
> _yet_ reflect that.*** NTFS ACLs do not quite translate to
> and from POSIX. The semantic differences mean that
> information is lost translating each direction.

Cygwin *does* support NTFS ACLs _now_ (I think the implementation is either
POSIX or POSIX-like). The semantics issues you mention above are very real,
but if Cygwin is functioning properly, rsync doesn't need to care.

> I have a vague recollection that NTFS
> also has some form of EAs.

It does, but not used much. I tried searching the MS Platform SDK, but
couldn't find any docs on them.

> If two like systems (windows<->windows for
> example) are communicating they could use their native ACL
> format instead of POSIX.

That would entail a native Windows port of rsync (or sidestepping Cygwin for
ACL handling).

Max.


-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html

Re: Copying EAs and ACLs

2003-03-02 Thread jw schultz 
On Sun, Mar 02, 2003 at 01:58:03PM -, Max Bowsher wrote:
> jw schultz wrote:
> > Although NTFS supports ACLs the cygwin environment does not
> > _yet_ reflect that.*** NTFS ACLs do not quite translate to
> > and from POSIX. The semantic differences mean that
> > information is lost translating each direction.
> 
> Cygwin *does* support NTFS ACLs _now_ (I think the implementation is either
> POSIX or POSIX-like). The semantics issues you mention above are very real,
> but if Cygwin is functioning properly, rsync doesn't need to care.
> 
> > I have a vague recollection that NTFS
> > also has some form of EAs.
> 
> It does, but not used much. I tried searching the MS Platform SDK, but
> couldn't find any docs on them.

Deprecated perhaps?

> > If two like systems (windows<->windows for
> > example) are communicating they could use their native ACL
> > format instead of POSIX.
> 
> That would entail a native Windows port of rsync (or sidestepping Cygwin for
> ACL handling).

I only mention the windows<->windows bit that because i
think it would be desirable to have the implementation allow
such support to be added at a later date if the
infrastructure permitted.

Thanks for the NTFS clarifications.

-- 

J.W. SchultzPegasystems Technologies
email address:  [EMAIL PROTECTED]

Remember Cernan and Schmitt
-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html

Re: Copying EAs and ACLs

2003-03-03 Thread Ben Escoto 
> "jws" == jw schultz <[EMAIL PROTECTED]>
> wrote the following on Sun, 2 Mar 2003 04:50:23 -0800

  jws> EAs seem to be unsupported by most of the UNIX platforms.  Pipe
  jws> up now if you know of support for them on any mainstream UNIX.

On the rdiff-backup mailing list I referenced your message and got
this response:

--
From: Greg Freemyer <[EMAIL PROTECTED]>
Date: Mon, 3 Mar 2003 18:00:23 -0500 (15:00 PST)
To: Ben Escoto <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>

 >>  For
 >>  a thoughtful summary of rsync's ACL/EA issues, see this message that
 >>  J.W. Schultz just posted to the rsync mailing list:

 >>  http://lists.samba.org/pipermail/rsync/2003-March/010031.html


Ben,

I'm not on the rsync mailing list, but the writer asks if any
mainstream UNIXs support EAs (as opposed to ACLs).

I know that the following do:
   VxFS  (from Veritas, heavily used in HP-UX and Solarix at a minimum)
   AdvFS (From Tru64 (i.e. Compaq/HP)) 
   UFS, NFS  (As patched for Tru64 from Compaq/HP) 
   XFS and CXFS (From SGI's UNIX  and their Linux XFS port as well).

So in the top 5 Commercial UNIXes, the only one that may not support
EAs is AIX.  (I don't know AIX).

FYI: Tru64 man page:
http://btrcx1.cip.uni-bayreuth.de/cgi-bin/manpages/proplist/4

Unfortunately, I don't know of any kind of compatibility amongst the
above, but I'm no expert.

Also, IIRC ACLs are required for DOD Orange Book qualified secure
installations.

Feel free to forward this info to the rsync list.

Greg
-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html

Re: Copying EAs and ACLs

2003-03-03 Thread jw schultz 
On Mon, Mar 03, 2003 at 05:29:50PM -0800, Ben Escoto wrote:
> > "jws" == jw schultz <[EMAIL PROTECTED]>
> > wrote the following on Sun, 2 Mar 2003 04:50:23 -0800
> 
>   jws> EAs seem to be unsupported by most of the UNIX platforms.  Pipe
>   jws> up now if you know of support for them on any mainstream UNIX.
> 
> On the rdiff-backup mailing list I referenced your message and got
> this response:

Thanks,  The link to the Tru64 manpage was particularly
helpful since i might never have found it given the
"proplist" name.

> --
> From: Greg Freemyer <[EMAIL PROTECTED]>
> Date: Mon, 3 Mar 2003 18:00:23 -0500 (15:00 PST)
> To: Ben Escoto <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
> 
> FYI: Tru64 man page:
> http://btrcx1.cip.uni-bayreuth.de/cgi-bin/manpages/proplist/4

-- 

J.W. SchultzPegasystems Technologies
email address:  [EMAIL PROTECTED]

Remember Cernan and Schmitt
-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html

Re: Copying EAs and ACLs

2003-03-09 Thread Ben Escoto 

How many bytes per file on average do you think EAs/ACLs will take up?


-- 
Ben Escoto


pgp0.pgp
Description: PGP signature
-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html

Re: Copying EAs and ACLs

2003-03-09 Thread Axel Thimm 
On Sun, Mar 02, 2003 at 04:50:23AM -0800, jw schultz wrote:
> Access Control Lists (ACLs) and Extended Attributes (EA) are
> an area i have seen for some time as something rsync will
> need to address.  I've put a tighter focus on this issue for
> the past week or so and have reached a few conclusions.
> 
> 1. ACL and EA OS support is growing but not really there yet.
> 2. Utility support is almost completely missing.
> 3. Use lags support dramatically.
> 4. ACLs and EAs are a part of the future.
> 
>   Users and admins are coming to linux and Unix with
>   the expectation of ACLs.  While intelligent use of
>   group IDs can more simply deal with _almost_ all
>   permissions issues, and by being simpler tend to be
>   more secure, many will prefer the quick fix ACLs
>   provide.
> [...]
> So while demand is currently low i believe that rsync will
> need to support ACLs and EAs in the near future or it will
> become little more than a limited download tool like ftp.

A very good analysis.

While indeed currently the pure Unix area has not such great need for ACLs,
there is a prominent area of application, which are Samba servers. If you
migrate a Windows domain controller/file server to Samba you will be
confronted with ACLs. You will either have to support them or present
alternatives, and usually the users will be accustomed to using GUIs under
Windows to adjust their ACLs.

The SGI group on XFS once commented that most XFS installations are due to the
ACL support, which is needed for this reason, and I have since seen a lot of
Samba/ACL systems popping up with rising trend.

Of course there are workarounds, like extracting the ACLs into a text dump,
rsyncing that and reapplying them on the other side, but a native rsync
support possibly converting between different ACL incarnations would be more
than nice to have.

Maybe samba's code on ACL abstraction can be "stolen"? After all samba & rsync
do have a prominent subset of authors ... ;)
-- 
[EMAIL PROTECTED]


pgp0.pgp
Description: PGP signature
-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html

Re: Copying EAs and ACLs

2003-03-09 Thread jw schultz 
On Sun, Mar 09, 2003 at 06:45:18PM +0100, Axel Thimm wrote:
> On Sun, Mar 02, 2003 at 04:50:23AM -0800, jw schultz wrote:
> > Access Control Lists (ACLs) and Extended Attributes (EA) are
> > an area i have seen for some time as something rsync will
> > need to address.  I've put a tighter focus on this issue for
> > the past week or so and have reached a few conclusions.
> > 
> > 1. ACL and EA OS support is growing but not really there yet.
> > 2. Utility support is almost completely missing.
> > 3. Use lags support dramatically.
> > 4. ACLs and EAs are a part of the future.
> > 
> > Users and admins are coming to linux and Unix with
> > the expectation of ACLs.  While intelligent use of
> > group IDs can more simply deal with _almost_ all
> > permissions issues, and by being simpler tend to be
> > more secure, many will prefer the quick fix ACLs
> > provide.
> > [...]
> > So while demand is currently low i believe that rsync will
> > need to support ACLs and EAs in the near future or it will
> > become little more than a limited download tool like ftp.
> 
> A very good analysis.

Thanks.

> While indeed currently the pure Unix area has not such great need for ACLs,
> there is a prominent area of application, which are Samba servers. If you
> migrate a Windows domain controller/file server to Samba you will be
> confronted with ACLs. You will either have to support them or present
> alternatives, and usually the users will be accustomed to using GUIs under
> Windows to adjust their ACLs.
> 
> The SGI group on XFS once commented that most XFS installations are due to the
> ACL support, which is needed for this reason, and I have since seen a lot of
> Samba/ACL systems popping up with rising trend.

That is the current trend.  Most UNIX admins are accustomed
to only having the UGO permissions masks and we have used
them to manage priveleges quite elegantly.  I expect that to
change.  As ACL support become ubiquitous habits will change
and new users will prominent among the early adopters.  And
as i said (quoted above) as users and admins move to UNIX
and Linux they will bring their expectations with them.

> Of course there are workarounds, like extracting the ACLs into a text dump,
> rsyncing that and reapplying them on the other side, but a native rsync
> support possibly converting between different ACL incarnations would be more
> than nice to have.
> 
> Maybe samba's code on ACL abstraction can be "stolen"? After all samba & rsync
> do have a prominent subset of authors ... ;)

The applicable code (if any) is likely to be but a small
portion of what will be needed.  Their experience
extracting/setting ACLs on multiple platforms should be
helpful.  Remember that unlike samba, the current rsync is
very POSIXish and isn't really about interoperability and i
am not suggesting that should change.


-- 

J.W. SchultzPegasystems Technologies
email address:  [EMAIL PROTECTED]

Remember Cernan and Schmitt
-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html

Re: Copying EAs and ACLs

2003-03-09 Thread jw schultz 
On Sun, Mar 09, 2003 at 08:55:21AM -0800, Ben Escoto wrote:
> 
> How many bytes per file on average do you think EAs/ACLs will take up?

There is no way to know.  It all depends on how they are
used.  What is your average file size and how many terabytes
of storage will you manage in two years? (rhetorical question)

In a binary purely POSIX form each ACE (Access Control
Entry) could be managed in 6 or 8 bytes but the libs don't
seem to have a documented portable binary format.  A POSIX
variable length text format would use 11-18 bytes for each
ACE depending on UID size (decimal) and type.  Non-POSIX or
portable ACEs would be larger of course.  If we strip out
the base ACL (what maps to the UGO mask) i imagine (blind
stab in the dark) the typical ACL might have only 3 or 4
ACEs so we would be looking at around 64 bytes plus
overhead, that is only a little smaller than our current
per-file structure.

As for EAs, who knows.  With just capabilities and other
security hooks it might be fairly small (one or two hundred
bytes).  Add resource forks, icons, thumbnails, signed
md5sums, other preferences, and who knows what else -- i
can't even guess.  At the moment Ext[23] limit EAs
(including the binary ACL) to one block (typically 4KB) but
the syscall and other filesystems (XFS at least) only limit
the size of each EA to 64KB and no limit on the number of
EAs per file.

What i do expect for the next few years is that almost all
files will have no EAs and that less than half will have
ACLs.  I do however expect that ACL usage will affect entire
trees (setfacl -R -m) rather than scattered files.



-- 

J.W. SchultzPegasystems Technologies
email address:  [EMAIL PROTECTED]

Remember Cernan and Schmitt
-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html

Re: Copying EAs and ACLs

2003-03-09 Thread Ben Escoto 
> "JWS" == jw schultz <[EMAIL PROTECTED]>
> wrote the following on Sun, 9 Mar 2003 18:25:47 -0800

  JWS> What i do expect for the next few years is that almost all
  JWS> files will have no EAs and that less than half will have ACLs.
  JWS> I do however expect that ACL usage will affect entire trees
  JWS> (setfacl -R -m) rather than scattered files.

Yes, this sounds likely to me also.  If so, it doesn't seem very
important to apply the rsync algorithm to the contents of the EAs/ACLs
- updating them as a whole if there is any change shouldn't be too
inefficient.

Also, if the ACL/EA information needs to be stored separately (because
for instance the target system doesn't have ACL/EA capability), does
it seem better then to use one big file, instead of, for instance, a
whole tree of smaller files?  I was thinking that maybe the file's
format could be the same as the (gzipped) output of getfattr/getfacl
--recursive.  That would make things more compatible, but may be
slightly inefficient compared to some other format.  Also there may be
no point if the getf[attr/acl] format is likely to change soon.


-- 
Ben Escoto


pgp0.pgp
Description: PGP signature
-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html

Re: Copying EAs and ACLs

2003-03-09 Thread jw schultz 
On Sun, Mar 09, 2003 at 10:31:16PM -0800, Ben Escoto wrote:
> > "JWS" == jw schultz <[EMAIL PROTECTED]>
> > wrote the following on Sun, 9 Mar 2003 18:25:47 -0800
> 
>   JWS> What i do expect for the next few years is that almost all
>   JWS> files will have no EAs and that less than half will have ACLs.
>   JWS> I do however expect that ACL usage will affect entire trees
>   JWS> (setfacl -R -m) rather than scattered files.
> 
> Yes, this sounds likely to me also.  If so, it doesn't seem very
> important to apply the rsync algorithm to the contents of the EAs/ACLs
> - updating them as a whole if there is any change shouldn't be too
> inefficient.

My concern is not just the average use for the next year or
two.  The lead time from beginning development to general
use is more than a year.  Even with only scattered use rsync
should support more than just the average.  We should be
supporting the corner cases, the sites where every file has
long ACLs or huge EAs on every file.  Once people start
really using this stuff the efficiencies will matter.

> Also, if the ACL/EA information needs to be stored separately (because
> for instance the target system doesn't have ACL/EA capability), does
> it seem better then to use one big file, instead of, for instance, a
> whole tree of smaller files?  I was thinking that maybe the file's
> format could be the same as the (gzipped) output of getfattr/getfacl
> --recursive.  That would make things more compatible, but may be
> slightly inefficient compared to some other format.

I've considered the issue of storing EA/ACL data on
filesystems that don't support them.  With the possible
exception of rsyncd it gets really ugly fast.  Rsync is for
syncing arbitrary files and directory trees.  This means
that this info would have to be stored along with the
files.  For that you need magic files or directories that
don't collide with the real ones.  No thanks.  The
facilities not supported by the filesystem won't be
transferred.  If you want to have a repository that stores
ACLs or EAs you should use a filesystem that does.

> 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.  The other
change would be for the proprietary platforms to add
compatibility interfaces.  Neither of these possibilities
negate the value of implementing support.


-- 

J.W. SchultzPegasystems Technologies
email address:  [EMAIL PROTECTED]

Remember Cernan and Schmitt
-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html

Re: Copying EAs and ACLs

2003-03-10 Thread Andreas Gruenbacher 
On Monday 10 March 2003 08:20, jw schultz wrote:
> On Sun, Mar 09, 2003 at 10:31:16PM -0800, Ben Escoto wrote:
> > > "JWS" == jw schultz <[EMAIL PROTECTED]>
> > > wrote the following on Sun, 9 Mar 2003 18:25:47 -0800
> >
> >   JWS> What i do expect for the next few years is that almost all
> >   JWS> files will have no EAs and that less than half will have ACLs.
> >   JWS> I do however expect that ACL usage will affect entire trees
> >   JWS> (setfacl -R -m) rather than scattered files.
> >
> > Yes, this sounds likely to me also.  If so, it doesn't seem very
> > important to apply the rsync algorithm to the contents of the EAs/ACLs
> > - updating them as a whole if there is any change shouldn't be too
> > inefficient.
>
> My concern is not just the average use for the next year or
> two.  The lead time from beginning development to general
> use is more than a year.  Even with only scattered use rsync
> should support more than just the average.  We should be
> supporting the corner cases, the sites where every file has
> long ACLs or huge EAs on every file.  Once people start
> really using this stuff the efficiencies will matter.
>
> > Also, if the ACL/EA information needs to be stored separately (because
> > for instance the target system doesn't have ACL/EA capability), does
> > it seem better then to use one big file, instead of, for instance, a
> > whole tree of smaller files?  I was thinking that maybe the file's
> > format could be the same as the (gzipped) output of getfattr/getfacl
> > --recursive.  That would make things more compatible, but may be
> > slightly inefficient compared to some other format.
>
> I've considered the issue of storing EA/ACL data on
> filesystems that don't support them.  With the possible
> exception of rsyncd it gets really ugly fast.  Rsync is for
> syncing arbitrary files and directory trees.  This means
> that this info would have to be stored along with the
> files.  For that you need magic files or directories that
> don't collide with the real ones.  No thanks.  The
> facilities not supported by the filesystem won't be
> transferred.  If you want to have a repository that stores
> ACLs or EAs you should use a filesystem that does.
>
> > 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.

--Andreas.
-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html

Re: Copying EAs and ACLs

2003-03-10 Thread 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. SchultzPegasystems Technologies
email address:  [EMAIL PROTECTED]

Remember Cernan and Schmitt
-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html

Re: Copying EAs and ACLs

2003-03-10 Thread 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 [EMAIL PROTECTED] I'm sorry but a simple format like the one you 
outlined is not general enough for future use.

Cheers,
Andreas.

-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html

Re: Copying EAs and ACLs

2003-03-10 Thread 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 [EMAIL PROTECTED]

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 tha