dovecot - Sep 2009 - 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL:
<http://dovecot.org/pipermail/dovecot/attachments/20090901/5b5081b3/attachment-0002.bin>

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.
-------------- 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/20090913/f5d171eb/attachment-0002.bin>