[Dovecot] Public Namespace & ACL & Virtual Users

[Fintec]

Thanks for the reply Timo.

I think one of my main problems is that: "Namespace prefixes are
currently ignored". My public namespace is defined as:

---------- snip ----------
namespace public {
   separator = .
   prefix = Public_Folders.
   location = maildir:/home/vmail/domains/%
d/Public_Folders:CONTROL=/home/vmail/domains/%d/%
n/Public_Folders/support:INDEX=/home/vmail/domains/%d/%
n/Public_Folders/index
   hidden = no
}
---------- snip ----------

This means when I try and add a dovecot-acl file into one of my
Public_Folders (in the public name space) it isn't seen at all. I
switched to using a vfile global acl which is at least seen but I'm
getting mixed results. To test I created /etc/dovecot-acls/Management:
user=user1 at domain.com lrwsiea
user=user2 at domain.com lrwsie

If I add any more of the ACLs, for example k dovecot reports:
dovecot: IMAP(user1 at domain.com): ACL file /etc/dovecot-acls/Management
line 1: Unknown ACL 'k'

This means I have been able to restrict access to the Management folder
but because I cannot add k to the ACL list I'm unable to create folders
within this. Also, when using the vfile global ACL
file  /etc/dovecot-acls/Management none of the other Public_Folder sub
directories are available at all!

In summary:
- dovecot-acl file within public namespace directory isn't found because
ACL ignores namespace prefix
- global ACLs partialy work with virtual users but currently not able to
do more than lrwsiea
- global ACLs stop other non-ACL restricted public namespace directories
working (in my configuration)

Any help with this would be greatly appreciated!

Gavin

On Tue, 2006-05-30 at 14:59 +0300, Timo Sirainen wrote:
> On Tue, 2006-05-30 at 11:28 +1200, Fintec wrote:
> > Our implementation of dovecot (v1.0b7) uses many virtual users and
> > domains and 1 actual user (vmail), all using maildir. So far I have
> > successfully created the public namespace (Public_Folders) which every
> > user can access but I'm having difficulty restricting access using ACls.
> > 
> > When trying to implement the dovecot ACL plug-in I followed the wiki
> > instructions and created a "dovecot-acl" file within Public_Folders
> > containing:
> > owner lrwstiekxa
> > user=user1 at domain.com lrwstiek
> > 
> > However this doesn't appear to do anything. All users can still access
> > Public_Folders so I have a couple of questions that hopefully someone
> > can help me with...
> 
> The problem here is that Dovecot assumes the logged in user owns the
> mailbox. The ACLs were currently meant mostly to work with master user
> logins, so the only case when owner doesn't match the logged in user is
> when a master user logs in as someone else.
> 
> How do you define mailbox's owner anyway in cases like this? If the
> mailbox exists in a public namespace, is anyone its owner? Well I guess
> I'll try to figure out this when I'm really implementing the proper
> shared mailbox support for Dovecot..
> 
> Anyway, this would work for you:
> 
> owner
> user=real-owner-user lrwstiekxa
> user=user1 at domain.com lrwstiek
> 
> Although after I tried it now, I found a bug which causes it to crash
> with the empty owner list. Or actually that same bug could cause it to
> break in other ways too, fix here:
> 
> http://dovecot.org/list/dovecot-cvs/2006-May/005609.html
> 
> > 2) Is it possible to create dovecot-acl files with virtual usernames,
> > i.e. user1 at domain.com or does it have to be actual users, i.e. vmail?
> 
> They must be virtual usernames.
> 
> > 3) Is it possible to restrict access within the namespace definition,
> > i.e. set up another public namespace restricted to manager at domain.com?
> 
> This sounds more like user-specific configuration, which is possible
> with a kludgy imap-wrapper script which sets up proper namespace
> environment variables before calling imap binary itself.
> 
> > 4) Is ACL accepts & denies logged somewhere other than /var/log/maillog
> > (my default)?
> 
> They're not logged anywhere currently. Is it really useful? Seems like
> it'd only fill up the logs. Optionally perhaps..
>