XFER ACL issue

[Wesley Craig]

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:

	http://cvs.itd.umich.edu/cgi-bin/cvsweb.cgi/lfs/cyrus- 
imap23/237p3.diff?rev=1.2

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.

:wes

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.