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. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20081116/a4c88f29/attachment-0002.bin>
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. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20081116/57748b55/attachment-0002.bin>
On Nov 16, 2008, at 5:09 AM, Timo Sirainen wrote:> Any thoughts?1. 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". 2. 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 194 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20081116/e6636aa5/attachment-0002.bin>
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. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20081116/7a848e5f/attachment-0002.bin>
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
This is awesome Timo! Now I guess I'll need to set up a test box to play with it some... -- Best regards, Charles
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 at 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 -- 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available URL: <http://dovecot.org/pipermail/dovecot/attachments/20090115/b6d3df7c/attachment-0002.bin>
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 | ++49-541-335 08 30 | 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: dovecot-owner-acl.diff Type: text/x-diff Size: 2598 bytes Desc: not available URL: <http://dovecot.org/pipermail/dovecot/attachments/20090205/1d72e51a/attachment-0002.bin>
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. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part URL: <http://dovecot.org/pipermail/dovecot/attachments/20090220/957f318c/attachment-0002.bin>