XFER ACL issue
wes at umich.edu
Wed Aug 2 21:03:50 EDT 2006
Excellent. Looks good. I'll try it out soon.
In the meantime, I have encountered another ACL issue, and I'd like
to propose a solution.
Because 2.3.x currently stores ACLs in non-legacy format, when these
non-legacy ACLs are stored in a 2.2.x MUPDATE server, 2.2.x frontends
report ACLs that have 'c' and 'd' rights stripped out. I suggest
that 2.3.x instead store ACLs in legacy format: that is, in the
format that rfc 4314 specifies for presentation to clients. When
reading these ACLs, the 2.2.x frontends would drop the new ACLs,
leaving the client with ACLs that properly represent what the client
is permitted to do.
The patch implementing this is here:
It also includes: a fix for the bug in backend.c which causes
sync_client to use the wrong network interface under some
circumstances; a reduction in the unnecessarily large amount of
memory that sync_server allocates for per-message pathnames; calls to
telemetry_rusage() to log per-user CPU logging. It also includes my
now-deprecated fix for the XFER ACL issue.
FWIW, these are the *only* patches I'm currently using in our mixed
2.2/2.3 environment, and I'm able to successfully XFER mailboxes back
and forth between 2.2 and 2.3 backends. I have several open issues,
related to XFER & replication, nothing that can't be worked around by
our admins until we can propose fixes.
On 02 Aug 2006, at 11:19, Ken Murchison wrote:
> Wesley Craig wrote:
>> I was tracking a very similar issue with xfer between 2.2 and
>> 2.3.6. xfer'ing vanilla 2.2.12 mailboxes to 2.3.6 seems to work
>> fine, and xfer'ing a 2.3.6 mailbox to 2.2.12 also more or less
>> works (permissions are broken since 2.3.6 blindly uses rfc 4314
>> ACLs rather than paying attention to whether the target backend
>> supports only legacy ACLs).
> I just tested and committed a fix for the XFER 2.3 -> 2,2 ACL issue.
More information about the Info-cyrus