fixing unixheirsep for 2.5

[Julien Coloos]

Le 15/02/2013 07:10, Bron Gondwana a écrit :
> Thanks for this!
>
> commit c95da833a910150bb8d55585d221237cf1b673d9
> Author: Julien Coloos <julien.coloos at atos.net>
> Date:   Mon Feb 11 15:36:05 2013 +0100
>
>      Various fixes for userid with dots and unixhierarchysep
>      Use correct (not internal) userid in ACLs when creating root level folder.
>      Fix ACLs setting when userid contains dots.
>      In pop3d, as for imapd, correctly handle userid with dots.
>
>
> Fixing the various unixheirsep and altnamespace cases to work correctly has been on my todo list for far too long.
>
> Anyone who's following along with 2.5 development and uses either of those two set to other than the default - I'd love your test results and bug reports.  I really want this rock solid by release.
>
> (anyone who can write test cases would be greatly appreciated too!)
>
> Thanks,
>
> Bron.

Here is a test case for the issues I fixed:
Repository: git://github.com/worldline-messaging/cassandane.git
Branch: ticket/3373
Commit: e866d3f134ed07663d2742113964ed91b80be831 
(https://github.com/worldline-messaging/cassandane/commit/e866d3f134ed07663d2742113964ed91b80be831)


Notice that there actually still exist incoherences regarding how userid 
is handled.
In most - if not all - places, the current master code deals with the 
internal representation of the userid, and thus in some places (usually 
when dealing with ACLs, as with my fix) there are conversions to its 
external form.

The incoherences arise when the external userid contains the character 
'^', which is the value used to represent dots in internal form when 
unix hierarchy separator is used.
For example both user ids "my.id" and "my^id" have the same mailbox 
(internal name: "user.my^id"). Thus if you set ACLs for "my^id" on 
mailbox (external name) "user/my.id", user "my^id" would be able to 
login in this mailbox.
In places where internal form is converted back to external, other kind 
of issues can happen: "my^id" is converted back to "my.id" which is not 
the actual external user id.

I believe that to fix those last issues, either '^' shall become 
forbidden with unix hierarchy separator enabled, or the code shall be 
refactored to receive (a structure knowing) both external and internal 
form of the user id.