[Dovecot] lazy-expunge acl bug?
Hi,
we've defined a public namespace "shared" and use the acl and lazy-expunge plugins among others. The problem is, that a mailbox is deleted by the DELETE-command without the x-flag to be set (# 1.2.9):
a myrights shared/aclDeleteTest
- MYRIGHTS "shared/aclDeleteTest" lrsed
a OK Myrights completed.
b delete shared/aclDeleteTest
b OK Delete completed.
c myrights shared/aclDeleteTest
c NO Mailbox doesn't exist: aclDeleteTest
This behavior should be different and the mailbox should not be deleted, should it? Is there a fast workaround?
Without the e-flag, mailboxes can't be deleted. But as some users should be allowed to use the expunge operation, it's no option to remove the e-flag...
thx Martin
Without the e-flag, mailboxes can't be deleted. But as some users should be allowed to use the expunge operation, it's no option to remove the e-flag...
Even with lrs-flags set only, deletion of mailbox is possible.
a myrights shared/testOrdner
- MYRIGHTS "shared/testOrdner" lrs a OK Myrights completed. a delete shared/testOrdner a OK Delete completed. a select shared/testOrdner a NO Mailbox doesn't exist: testOrdner
thx Martin
On ma, 2010-06-07 at 11:00 +0200, Martin Ott wrote:
we've defined a public namespace "shared" and use the acl and lazy-expunge plugins among others. The problem is, that a mailbox is deleted by the DELETE-command without the x-flag to be set (# 1.2.9):
Looks like the plugin ordering code is a complete mess and it just happens to work in most situations.. It's now fixed properly in v2.0, but for v1.2 the only solutions would be:
a) Backport major plugin API redesign changes from v2.0.
b) Try to add some hack that possibly fixes some situation, but possibly breaks another one..
I'm not really happy with either of those choices. Few people have complained about problems related to this, so I think I'll just leave it as it is in v1.2.
Am 07.06.2010 18:23, schrieb Timo Sirainen:
On ma, 2010-06-07 at 11:00 +0200, Martin Ott wrote:
we've defined a public namespace "shared" and use the acl and lazy-expunge plugins among others. The problem is, that a mailbox is deleted by the DELETE-command without the x-flag to be set (# 1.2.9):
Looks like the plugin ordering code is a complete mess and it just happens to work in most situations.. It's now fixed properly in v2.0, but for v1.2 the only solutions would be:
a) Backport major plugin API redesign changes from v2.0.
b) Try to add some hack that possibly fixes some situation, but possibly breaks another one..
I'm not really happy with either of those choices. Few people have complained about problems related to this, so I think I'll just leave it as it is in v1.2.
After the dovecot-update (mercurial) the problem has disappeared - perhaps due to http://hg.dovecot.org/dovecot-1.2/rev/029c3afcfbd0 - acl in the public namespace work properly now.
As we extensively use folders in the public namespace and users permitted to expunge messages, it would be very convenient if the lazy_expunge plugin worked in this namespace as well. A practical behavior could be to store expunged mailboxes and mails in a seperate, non-user specific, folder. Is it possible to extend the lazy_expunge plugin towards this behavior?
Martin
On ke, 2010-06-09 at 08:28 +0200, Martin Ott wrote:
As we extensively use folders in the public namespace and users permitted to expunge messages, it would be very convenient if the lazy_expunge plugin worked in this namespace as well. A practical behavior could be to store expunged mailboxes and mails in a seperate, non-user specific, folder. Is it possible to extend the lazy_expunge plugin towards this behavior?
Maybe lazy_expunge_public setting that's equivalent to lazy_expunge setting, except is used for public namespaces. But ACLs could make it problematic..
Am 11.06.2010 16:49, schrieb Timo Sirainen:
On ke, 2010-06-09 at 08:28 +0200, Martin Ott wrote:
As we extensively use folders in the public namespace and users permitted to expunge messages, it would be very convenient if the lazy_expunge plugin worked in this namespace as well. A practical behavior could be to store expunged mailboxes and mails in a seperate, non-user specific, folder. Is it possible to extend the lazy_expunge plugin towards this behavior?
Maybe lazy_expunge_public setting that's equivalent to lazy_expunge setting, except is used for public namespaces. But ACLs could make it problematic..
Maybe ACLs could be copied to the expunged folder. There could also be an option whether the expunged folder inherits the original ACsL or if a global ACL should be applied, such that e.g. only the mailadmin gets write access to the expunged folder.
On pe, 2010-06-11 at 17:23 +0200, Martin Ott wrote:
Maybe lazy_expunge_public setting that's equivalent to lazy_expunge setting, except is used for public namespaces. But ACLs could make it problematic..
Maybe ACLs could be copied to the expunged folder.
ACLs could change, so I don't think copying is ok. Adding some logic to always use the original one's ACLs would be better, but I don't know how difficult that would be to implement.
There could also be an option whether the expunged folder inherits the original ACsL or if a global ACL should be applied, such that e.g. only the mailadmin gets write access to the expunged folder.
Some global default ACL might be easier, but that's not very flexible.
Anyway, this is pretty low priority on my todo list.
Am 11.06.2010 17:31, schrieb Timo Sirainen:
On pe, 2010-06-11 at 17:23 +0200, Martin Ott wrote:
Maybe lazy_expunge_public setting that's equivalent to lazy_expunge setting, except is used for public namespaces. But ACLs could make it problematic..
Maybe ACLs could be copied to the expunged folder.
ACLs could change, so I don't think copying is ok. Adding some logic to always use the original one's ACLs would be better, but I don't know how difficult that would be to implement.
There could also be an option whether the expunged folder inherits the original ACsL or if a global ACL should be applied, such that e.g. only the mailadmin gets write access to the expunged folder.
Some global default ACL might be easier, but that's not very flexible.
Anyway, this is pretty low priority on my todo list.
thanks for your points - now I see the arising dificulties
Anyway, for the private namespace lazy_expunge plugins stays a very convenient method to restore mailboxes and mails from users who accidently expunged them.
thank you!
Martin
participants (2)
-
Martin Ott
-
Timo Sirainen