[Dovecot] IMAP ACLs and global ACLs in v1.2
I just committed code for IMAP ACL support based on the code from Kolab people. I did quite large changes though.
I also changed how global ACLs are handled. Previously local ACLs could override global ACLs, but now that users are able to modify the ACLs I think it should be the other way around. From what I've heard global ACLs are typically added for things like 1) disallowing user from doing something in specific mailboxes such as expunge messages, 2) giving a specific master user access to some mailboxes ONLY, such as voicemail.
For 1) case a user really shouldn't be able to grant himself privileges back but still should be able to share the mailbox to others (so the global ACL should have 'a' privilege). For 2) case a user shouldn't be able to remove privileges from the voicemail.
So now the user can freely update the local ACLs in whatever way he wants. But in the end if there are any global ACLs, all the local ACLs for those identifiers are ignored. Also local negative identifiers are ignored, so that e.g. global "user=foo lr" can't be disabled by a local "-user=foo lr" ACL.
I guess I should update the Wiki ACL page about how exactly the ACLs are applied now that they're well in my memory. :)
One thing I'm not really sure about is the "owner" handling. IMAP ACL specifications have no such concept. I think many/most other servers simply add a default ACL for the user name directly. It's a useful concept though, especially with the global ACLs. So currently Dovecot replies:
x getacl inbox
- ACL "inbox" "owner" lrwstiekxacd
x OK Getacl completed.
But should it just internally convert "owner" to "username" when replying? But then again if there's a separate rule directly for the "username" it breaks.
Do any of the existing ACL-capable IMAP clients want to see the username in the ACL reply or can they handle "owner" just fine?
Also what about global ACLs? The current code just lists them twice with local ACLs, which is definitely wrong:
x getacl foo
- ACL "foo" "xx" w "xx" lr "owner" lrwstiekxacd
x OK Getacl completed.
Perhaps the global ACLs could have a prefix character? Maybe '#'? Which reminds me, the current dovecot-acl file is mapped to IMAP ACLs like this:
dovecot-acl : IMAP ACL
- anyone : anyone
- authenticated : authenticated
- owner : owner
- user=name : name
- group=name : $name
- group-override=name : !$name
So all global ACLs would get the # prefix, like #anyone, #name, #!$name.
Any thoughts?
BTW. Listing shared mailboxes still doesn't work. I guess we'll see tomorrow if I still have energy to get that done.
On Nov 16, 2008, at 5:09 AM, Timo Sirainen wrote:
Any thoughts?
Also: Users probably shouldn't be able to remove administrator access
from themselves in their own mailboxes? A global ACL would be able to
do that, but if there are no global ACLs I'm thinking that the admin
access would be allowed regardless of how the local ACLs are
configured. The admin access could be removed by one of owner, user or
group-override. I think maybe SETACL owner could refuse to drop the
'a' right (wouldn't give an error, but it would just not remove it),
but if user or group-override drops the admin right there's nothing to
be done there. Instead then GETACL's output just wouldn't match
MYRIGHTS output.
I'm not sure what to do about ACLs when renaming a private mailbox to
shared namespace. Currently this isn't even possible, but it should be
pretty easy to implement. In this case user could lose access to the
entire mailbox if ACLs aren't set properly. Perhaps the RENAME could
add user=<name> <all rights> automatically when renaming the mailbox?
And if adding that didn't give user 'lra' rights (because of group-
override or global ACLs) it would refuse the RENAME? After those
checks at least it would be guaranteed that user has some access to
the mailbox and hopefully even be able to RENAME it back if it was an
accident.
On Nov 16, 2008, at 5:09 AM, Timo Sirainen wrote:
Any thoughts?
- How to handle "anyone" and "authenticated"? It might be nice to let
users share mailboxes, but if they'll start spamming their mailboxes
visible to everyone it'll get really annoying and fast. So I'm
thinking about a setting:
acl_anyone = allow : Let them do what they intended to do. Admins
could have this setting set.
acl_anyone = disallow : Don't allow user to add any ACLs with them.
Fail with NO if tried.
acl_anyone = domain : Treat them as alias for user=@domain which
matches all users from the user's domain (user=@domain matching not
implemented yet).
The default would probably be "disallow".
- There probably need to be some limits to how many different users
and groups can be used by ACLs and perhaps a limit to how many ACLs in
general each mailbox can have. The latter limit could be configurable,
defaulting to 100 maybe?
The former then would require tracking the users and groups somehow.
Actually the reason why I'm even thinking about it is because of
mailbox listing. I was planning on storing to a dict sharing_user/
acl_user and sharing_user/acl_group keys for each (non-negative) ACL
in user's mailboxes. So to prevent user from spamming the dict full
there would have to be some kind of a limit for this. Again perhaps
100 as the default. The current value could always be read by
iterating through sharing_user/* in dict and counting how many entries
there are.
On Sun, 2008-11-16 at 05:09 +0200, Timo Sirainen wrote:
BTW. Listing shared mailboxes still doesn't work. I guess we'll see tomorrow if I still have energy to get that done.
Initial implementation done. It still could use optimizations though. Also it may incorrectly list users who look like they'd have mailboxes shared to us but don't actually.
It uses a dictionary. I tested with a file base dict, but it should work with SQL and Berkeley DB too. It creates entries like:
shared/shared-boxes/user/plop/tss 1 shared/shared-boxes/user/tss/tss 1 shared/shared-boxes/group/bar/tss 1 shared/shared-boxes/group/foo/tss 1 shared/shared-boxes/group/foo/someone 1
The above means that user "tss" has shared mailboxes to groups "foo" and "bar" and to user "plop". Also user "someone" has shared mailboxes to group "foo". So to find out whose mailboxes we (may) have access to we'll iterate through:
- .../anyone/
- .../user/<my username>/
- .../group/<my group #1>/
- .../group/<my group #2>/
- etc.
The initial scan is done when a LIST command is supposed to list shared mailboxes (so clients using only subscriptions can avoid this entirely). The results are cached for an hour, after that does another scan to see if there are new visible users.
Hi there, got my ago problems working. now the last step i dont get working , quota for user in virtual user/domain setup.
in dovecot.conf i added =
mail_plugins = antispam quota imap_quota plugin { user_query = SELECT home, uid, gid, concat('*:storage=', quota_bytes, 'B') AS quota_rule FROM users WHERE userid = '%u' }
on test, the quota dont work. i set in postfixadmin quota 30mb fpr the testaccount and can send more then 40 mb to it by 8x 5mb attachements.
any1 of you can give me a hint ? i dont understand at all anything of mysql then setup or changing values with phpmyadmin. maybe the "user_query" is totaly wrong ?
thanks
marko
On Sun, 2008-11-16 at 20:20 +0100, Marko Weber wrote:
plugin { user_query = SELECT home, uid, gid, concat('*:storage=', quota_bytes, 'B') AS quota_rule FROM users WHERE userid = '%u' }
user_query is supposed to be in dovecot-sql.conf, not in plugin section.
This is awesome Timo!
Now I guess I'll need to set up a test box to play with it some...
Hi Timo, Hi List,
It's been a while since our last post (talking for "the Kolab guys" here). Sorry for that but we were very busy on various subjects -- and Christmas, New-year and all that exhausting holidays ... ;-)
I'm very happy to see all the features needed by Kolab integrated in 1.2. Unfortunately I wasn't able to give it some thorough testing, yet ... but I really hope to find the time to do so soon, so that we can migrate our work on Kolab+Dovecot to the current 1.2 head.
Timo Sirainen tss@iki.fi writes: [...]
One thing I'm not really sure about is the "owner" handling. IMAP ACL specifications have no such concept. I think many/most other servers simply add a default ACL for the user name directly. It's a useful concept though, especially with the global ACLs. So currently Dovecot replies:
x getacl inbox
- ACL "inbox" "owner" lrwstiekxacd
x OK Getacl completed.
But should it just internally convert "owner" to "username" when replying?
From our experience this would be a very good idea. Many clients recognize the username and handle those ACLs differently in there UI (for example they don't offer them for editing). But they don't understand "owner".
But then again if there's a separate rule directly for the "username" it breaks.
I think this would be primarily show an configuration or migration problem. Maybe "owner" should take precedence over those rules? In general I think, that in an sane setup only the owner rule should exist and when it maps to the username in the IMAP front end the should be no way to existentially create seperate rules for the owners username.
cheers sascha
Hi all,
On 15.01.2009, Sascha Wilde wrote:
But should it just internally convert "owner" to "username" when replying?
From our experience this would be a very good idea. Many clients recognize the username and handle those ACLs differently in there UI (for example they don't offer them for editing). But they don't understand "owner".
To work around this, we created a patch that tries to avoid the owner ACL entries. It does not translate between "owner" and username in the imap-acl plugin, but tries not to automatically create an ACL owner entries. Having implemented this patch now, I wonder whether the translation wouldn't have been simpler and better. Anyway, the main goal of the patch is to work around the problems we've observed with some clients when they encounter "owner" ACL entries so that we can get on with testing.
I don't think the patch is the right solution to the problem, but I've included it anyway. Maybe it's useful for a discussion.
Cheers,
Bernhard
Bernhard Herzog schrieb:
Hi all,
On 15.01.2009, Sascha Wilde wrote:
But should it just internally convert "owner" to "username" when replying?
From our experience this would be a very good idea. Many clients recognize the username and handle those ACLs differently in there UI (for example they don't offer them for editing). But they don't understand "owner".
To work around this, we created a patch that tries to avoid the owner ACL entries. It does not translate between "owner" and username in the imap-acl plugin, but tries not to automatically create an ACL owner entries. Having implemented this patch now, I wonder whether the translation wouldn't have been simpler and better. Anyway, the main goal of the patch is to work around the problems we've observed with some clients when they encounter "owner" ACL entries so that we can get on with testing.
I don't think the patch is the right solution to the problem, but I've included it anyway. Maybe it's useful for a discussion.
Cheers,
Bernhard
Hi,
i dont think you should mess around what clients think where should this end , the technical right and most clear description is owner, username can be very wide interpreted and may lead to technical problems in reading imap-acl i.e from horde imp or other mail clients later, as far i remember owner is use i.e in exchange too
what may help would be is additionial username info to owner dont no if this can be coded.
Using shared folder , a client has to understand how to use the system and read faqs, this is the same on all exist shared folder using mail/imap systems
just my thoughts no flame anyway thx for coding
Robert Schetterer robert@schetterer.org writes:
Bernhard Herzog schrieb:
On 15.01.2009, Sascha Wilde wrote:
But should it just internally convert "owner" to "username" when replying?
From our experience this would be a very good idea. Many clients recognize the username and handle those ACLs differently in there UI (for example they don't offer them for editing). But they don't understand "owner".
To work around this, we created a patch that tries to avoid the owner ACL entries.
[...]
i dont think you should mess around what clients think where should this end , the technical right and most clear description is owner, username can be very wide interpreted and may lead to technical problems in reading imap-acl i.e from horde imp or other mail clients later, as far i remember owner is use i.e in exchange too
Hi Robert,
I'm not quite sure if we are talking about the same thing. This is about the reply to the getacl command in the imap protocol (in opposite to the output in the clients UI).
I don't know about exchange, but most clients don't know about dovecots special meaning of "owner" but simply consider it an ordinary user name.
On the other hand I know horde imp (the Kolab Webclient is horde based) and I can assure you that it gets confused by dovecots current behavior: it does not recognize "owner" as "the actual owner of that mailbox" and does not handle the ACL in any special way while it _does_ recognize when the returned username is matching the current user and for instance horde prevents the user from changing his own right.
Further more there is no way in the IMAP ACL extension to determine the "owner" of an mailbox I'm aware of, so there would be no way for an client to resolve the "owner" ACL to an actual user, which makes the information rather useless.
cheers
Sascha Wilde OpenPGP key: 4BB86568 http://www.intevation.de/~wilde/ http://www.intevation.de/ Intevation GmbH, Neuer Graben 17, 49074 Osnabrück; AG Osnabrück, HR B 18998 Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
Hi Sascha,
Sascha Wilde schrieb:
Robert Schetterer robert@schetterer.org writes:
Bernhard Herzog schrieb:
On 15.01.2009, Sascha Wilde wrote:
But should it just internally convert "owner" to "username" when replying?
From our experience this would be a very good idea. Many clients recognize the username and handle those ACLs differently in there UI (for example they don't offer them for editing). But they don't understand "owner".
To work around this, we created a patch that tries to avoid the owner ACL entries.
[...]
i dont think you should mess around what clients think where should this end , the technical right and most clear description is owner, username can be very wide interpreted and may lead to technical problems in reading imap-acl i.e from horde imp or other mail clients later, as far i remember owner is use i.e in exchange too
Hi Robert,
I'm not quite sure if we are talking about the same thing. This is about the reply to the getacl command in the imap protocol (in opposite to the output in the clients UI).
i was talking about imap getacl, which answers owner but youre right maybe we missunderstood
I don't know about exchange, but most clients don't know about dovecots special meaning of "owner" but simply consider it an ordinary user name.
do you mean clients as humans or mail clients? there are less mail clients which understand imap acl at all the only only i know which works right fully in the that way is mulberry and horde imp, thunderbird can read acls but nor set ( shame on tb hackers ) and it reports simply owner etc ( but i should try the english version ....)
On the other hand I know horde imp (the Kolab Webclient is horde based) and I can assure you that it gets confused by dovecots current behavior: it does not recognize "owner" as "the actual owner of that mailbox" and does not handle the ACL in any special way while it _does_ recognize when the returned username is matching the current user and for instance horde prevents the user from changing his own right.
on my latests test with horde imp latest i cant find any problems with imap acl and owner, there where a few updates with acl lately and i had to mess around with the config but made it work, but for sure i couldnt test all features for now very deep, cause i still have bugs with other dovecot new features like virtual plugin
Further more there is no way in the IMAP ACL extension to determine the "owner" of an mailbox I'm aware of, so there would be no way for an client to resolve the "owner" ACL to an actual user, which makes the information rather useless.
i thought so
cheers
whatever what i mean was leave the code to standarts dont try to implement specials for brain bugged humans which might leave to other tec problems later, anyway i am not in the case to forbid something *g i ll trust on you that you know what youre doing at last *ggg
Robert Schetterer robert@schetterer.org writes:
Sascha Wilde schrieb:
Robert Schetterer robert@schetterer.org writes:
Bernhard Herzog schrieb:
On 15.01.2009, Sascha Wilde wrote:
But should it just internally convert "owner" to "username" when replying?
From our experience this would be a very good idea. Many clients recognize the username and handle those ACLs differently in there UI (for example they don't offer them for editing). But they don't understand "owner".
To work around this, we created a patch that tries to avoid the owner ACL entries.
[...]
i dont think you should mess around what clients think where should this end , the technical right and most clear description is owner, username can be very wide interpreted and may lead to technical problems in reading imap-acl i.e from horde imp or other mail clients later, as far i remember owner is use i.e in exchange too
I'm not quite sure if we are talking about the same thing. This is about the reply to the getacl command in the imap protocol (in opposite to the output in the clients UI).
i was talking about imap getacl, which answers owner
Me too.
[...]
I don't know about exchange, but most clients don't know about dovecots special meaning of "owner" but simply consider it an ordinary user name.
do you mean clients as humans or mail clients?
Mail clients == software speaking IMAP aware of the IMAP ACL extension.
[...]
whatever what i mean was leave the code to standarts
I agree, and we do. Problem is, while not prohibited by the standard keywords like "owner" are not defined by the standard. Even worse: there is no way in IMAP ACL to distinct such special keywords from actual user names.
Please see the first footnote in my latest mail in the thread "v1.2.beta1 released" Message-ID: s7wskmj26vr.fsf@intevation.de for more details.
cheers sascha
On Thu, 2009-01-15 at 17:48 +0100, Sascha Wilde wrote:
But should it just internally convert "owner" to "username" when replying?
From our experience this would be a very good idea. Many clients recognize the username and handle those ACLs differently in there UI (for example they don't offer them for editing). But they don't understand "owner".
GETACL now converts owner to username when ACLs contain owner right, but no username right.
Timo Sirainen tss@iki.fi writes:
On Thu, 2009-01-15 at 17:48 +0100, Sascha Wilde wrote:
But should it just internally convert "owner" to "username" when replying?
From our experience this would be a very good idea. Many clients recognize the username and handle those ACLs differently in there UI (for example they don't offer them for editing). But they don't understand "owner".
GETACL now converts owner to username when ACLs contain owner right, but no username right.
Great, thanks. A quick test looks perfect. :)
cheers sascha
participants (6)
-
Bernhard Herzog
-
Charles Marcus
-
Marko Weber
-
Robert Schetterer
-
Sascha Wilde
-
Timo Sirainen