Re: [Dovecot] Global ACL configuration problems: mailboxes not visible , set ACLs not honoured
On Tuesday 01 September 2009 12:11:39 Thomas Leuxner wrote:
On Tue, Sep 01, 2009 at 11:34:16AM +0200, Andreas Ntaflos wrote:
Is there anything more to it? I ask, because I can't seem to get it to work correctly using this approach with global ACLs. Problems include:
- Can't get the mailboxes "Spam" and "Ham" under the "Public" namespace to show up in the mail client (Thunderbird, KMail, Horde/IMP) at all. These have the ACL "authenticated lrwstipk" set so the should be visible to authenticated clients, shouldn't they? All I see is the namespace with no mailboxes beneath it.
Hi Andreas,
did you try with enabling the logging option 'mail_debug = yes'? It should then verbosely log ACLs read while accessing the folders. How about the files 'dovecot-acl' and 'dovecot-acl-list'? Are they present in your public root? The latter should have been automatically created once the subdirs have working ACLs.
Hi Thomas,
thanks for your helpful reply. I hadn't thought of setting mail_debug, don't know why :) Now I can see more clearly.
It seems that ACL files such as "/etc/dovecot/acls/Backup.received" or "/etc/dovecot/acls/Backup.sent" are read, but when accessing the actual mailbox Dovecot looks for a file "/etc/dovecot/acls/received" or "/etc/dovecot/acls/sent". I.e. the mailbox names *without* the namespace prefix. This can't be the desired behaviour, can it?
When I create such an ACL file (""/etc/dovecot/acls/sent") the defined restrictions seem to be applied. At least KMail doesn't even offer to "Delete message" anymore. Thunderbird does and messages can apparently be deleted, but they show up again upon reloading the folder. This is probably a Thunderbird issue. Horde/IMP is similar in this regard.
The Public namespace however doesn't seem to be given any consideration at all by Dovecot. I can see the namespace root ("Public") in the folder subscription list, but nothing beneath it. Even when I apply the "fix" described in the previous paragraphs I still can't see any of the public folders. The log file doesn't show anything about this either.
There are no "dovecot-acl" files at all, anywhere. I want to avoid having to use them, which is why I am trying to get global ACLs to work. The "dovecot-acl-list" files are created in every root directory, i.e. /var/mail/public/dovecot-acl-list, /var/vmail/example.org/username/Maildir/dovecot-acl-list and /var/vmail/example.org/username/Maildir-backup/dovecot-acl-list.
All three are empty.
So, the second issue (private namespace ACLs) could be a bug in Dovecot, unless I misunderstood how to name ACL files for mailboxes in other private namespaces. The first issue (invisibility of public folders) is still a mystery to me.
Ideas?
Thanks again for your reply!
Andreas
Andreas Ntaflos Vienna, Austria
GPG Fingerprint: 6234 2E8E 5C81 C6CB E5EC 7E65 397C E2A8 090C A9B4
On Tue, Sep 01, 2009 at 01:48:38PM +0200, Andreas Ntaflos wrote:
So, the second issue (private namespace ACLs) could be a bug in Dovecot, unless I misunderstood how to name ACL files for mailboxes in other private namespaces. The first issue (invisibility of public folders) is still a mystery to me.
Ideas?
I know you want it handled with global ACLs, but for testing you could place a 'dovecot-acl' with 'anyone lr" in the public vmail root. Just too see if clients list folders then. For the mail client behavior, I can confirm that some still seem to allow deleting mails, but the server blocks them from doing so in reality. I suppose this is a client glitch, like you mentioned.
I remember Timo saying that global ACLs aren't the tool of trade for some things you want to achieve, but I have to leave your "expected design" questions to him.
Thomas
On Tue, 2009-09-01 at 13:48 +0200, Andreas Ntaflos wrote:
It seems that ACL files such as "/etc/dovecot/acls/Backup.received" or "/etc/dovecot/acls/Backup.sent" are read, but when accessing the actual mailbox Dovecot looks for a file "/etc/dovecot/acls/received" or "/etc/dovecot/acls/sent". I.e. the mailbox names *without* the namespace prefix. This can't be the desired behaviour, can it?
No, but I don't think it's a good idea to change the behavior anymore since existing installations could depend on it. I added this fix to v2.0 code tree.
The Public namespace however doesn't seem to be given any consideration at all by Dovecot. I can see the namespace root ("Public") in the folder subscription list, but nothing beneath it. Even when I apply the "fix" described in the previous paragraphs I still can't see any of the public folders. The log file doesn't show anything about this either.
Are you using "owner" rights in there? Public mailboxes don't have an owner. "authenticated" is probably what you mean there.
participants (3)
-
Andreas Ntaflos
-
Thomas Leuxner
-
Timo Sirainen