[Dovecot] Public Namespace & ACL & Virtual Users
Background:
I am wanting to create shared folders (public namespace) with access control lists on the sub directories.
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@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...
- Is it possible to use the dovecot's ACL plug-in on a Public name
space?
- Is it possible to create dovecot-acl files with virtual usernames,
i.e. user1@domain.com or does it have to be actual users, i.e. vmail?
- Is it possible to restrict access within the namespace definition,
i.e. set up another public namespace restricted to manager@domain.com?
- Is ACL accepts & denies logged somewhere other than /var/log/maillog
(my default)?
- Is anyone successfully set-up an environment with a public namespace
and ACLs?
Any help would be greatly appreciated.
Gavin
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@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@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
- Is it possible to create dovecot-acl files with virtual usernames,
i.e. user1@domain.com or does it have to be actual users, i.e. vmail?
They must be virtual usernames.
- Is it possible to restrict access within the namespace definition,
i.e. set up another public namespace restricted to manager@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.
- 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..
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@domain.com lrwsiea user=user2@domain.com lrwsie
If I add any more of the ACLs, for example k dovecot reports: dovecot: IMAP(user1@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@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@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
- Is it possible to create dovecot-acl files with virtual usernames,
i.e. user1@domain.com or does it have to be actual users, i.e. vmail?
They must be virtual usernames.
- Is it possible to restrict access within the namespace definition,
i.e. set up another public namespace restricted to manager@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.
- 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..
Fintec wrote:
If I add any more of the ACLs, for example k dovecot reports: dovecot: IMAP(user1@domain.com): ACL file /etc/dovecot-acls/Management line 1: Unknown ACL 'k'
are you using 1.0beta7 or earlier? i believe this is fixed in beta8. (see acl-backend-vfile.c)
good luck!
Thanks for the tip HenkJan,
I'll go and try and find and beta8 RHEL 4 RPM upgrade package.Anyone out their built one yet? I've been using the Ignacio's, which have been fantastic, but he hasn't built a beta8 one yet.
Gavin
On Thu, 2006-06-01 at 09:22 +0200, HenkJan Wolthuis wrote:
Fintec wrote:
If I add any more of the ACLs, for example k dovecot reports: dovecot: IMAP(user1@domain.com): ACL file /etc/dovecot-acls/Management line 1: Unknown ACL 'k'
are you using 1.0beta7 or earlier? i believe this is fixed in beta8. (see acl-backend-vfile.c)
good luck!
I have re-tested with beta9 from src but unfortunately the results are fairly similar. The Public namespace (Shared Public Folders) work great until I try and and control access with the ACL plugin.
Problems are:
- dovecot-acl file within public namespace directory isn't found
- global ACLs (vfile) partially work with virtual users but when used: a) non-ACL restricted public namespace directories stop working b) permitted users are unable to view or create sub-folders
I think all the above problems can be attributed to the fact the ACL plugin ignores the namespace prefix. I did further testing with the vfile using some suggestions from the list:
VFILE TESTING: ("vmail" is the local user)
owner lrwstiekxa user=vmail lrwstiekxa user=virtualuser1@domain.com lrwstiek
Dovecot Log: child 8872 (imap) killed with signal 11
owner user=vmail lrwstiekxa user=virtualuser1@domain.com lrwstiek
Dovecot Log: child 8872 (imap) killed with signal 11
user=vmail lrwstiekxa user=virtualuser1@domain.com lrwstiek
Problems 2 (a) and (b) still exist. Sub-folder *is* created but not accessible
user=virtualuser1@domain.com lrwstiek
Problems 2 (a) and (b) still exist. Sub-folder *is* created but not accessible
Ideally I would like to use per-mailbox ACLs (dovecot-acl files) so I could easily be selective on what directories were access controlled, does anyone have a fix for this?
I have a couple of clients requiring access controlled Public Shared Folders so sponsoring the fix/development is not out of the question.
Regards, Gavin
On Thu, 2006-06-01 at 10:40 +1200, Fintec wrote:
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@domain.com lrwsiea user=user2@domain.com lrwsie
If I add any more of the ACLs, for example k dovecot reports: dovecot: IMAP(user1@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@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@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
- Is it possible to create dovecot-acl files with virtual usernames,
i.e. user1@domain.com or does it have to be actual users, i.e. vmail?
They must be virtual usernames.
- Is it possible to restrict access within the namespace definition,
i.e. set up another public namespace restricted to manager@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.
- 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..
On Thu, 2006-06-15 at 13:58 +1200, Fintec wrote:
I think all the above problems can be attributed to the fact the ACL plugin ignores the namespace prefix. I did further testing with the vfile using some suggestions from the list:
Could be, but supporting the namespace prefixes requires larger changes. Not going to happen before v1.0 release.
VFILE TESTING: ("vmail" is the local user)
Local user as in the UID of the process? That doesn't matter since only virtual users are matched.
owner lrwstiekxa user=vmail lrwstiekxa user=virtualuser1@domain.com lrwstiek
Dovecot Log: child 8872 (imap) killed with signal 11
It shouldn't be crashing. Could you get gdb backtrace of it? See http://dovecot.org/bugreport.html
I have re-tested with RC2 and dovecot no longer crashes so the ACL plug-in is looking good, as is, for Dovecot 1.0 stable.
However the following ACL usability problems still exist:
- dovecot-acl file within public namespace directory isn't found
- global ACLs (vfile) partially work with virtual users but when used: a) non-ACL restricted public namespace directories stop working b) permitted users are unable to view or create sub-folders
Hopefully Timo has time to look at these problems after the 1.0 stable release because it would really help us here and I'm sure others would love to see access controlled Public Shared Folders.
As I am not a programmer I am unable to help coding wise but as we have a couple of clients requiring access controlled Public Shared Folders sponsoring the fix/development is not out of the question.
Testing Results:
VFILE TESTING:
owner lrwstiekxa user=virtualuser1@domain.com lrwstiekxa
Problems 2 (a) and (b) still exist. Sub-folder *is* created but not accessible
owner user=virtualuser1@domain.com lrwstiekxa
Problems 2 (a) and (b) still exist. Sub-folder *is* created but not accessible
user=virtualuser1@domain.com lrwstiek
Problems 2 (a) and (b) still exist. Sub-folder *is* created but not accessible
Regards, Gavin
On Sun, 2006-06-18 at 01:33 +0300, Timo Sirainen wrote:
On Thu, 2006-06-15 at 13:58 +1200, Fintec wrote:
I think all the above problems can be attributed to the fact the ACL plugin ignores the namespace prefix. I did further testing with the vfile using some suggestions from the list:
Could be, but supporting the namespace prefixes requires larger changes. Not going to happen before v1.0 release.
VFILE TESTING: ("vmail" is the local user)
Local user as in the UID of the process? That doesn't matter since only virtual users are matched.
owner lrwstiekxa user=vmail lrwstiekxa user=virtualuser1@domain.com lrwstiek
Dovecot Log: child 8872 (imap) killed with signal 11
It shouldn't be crashing. Could you get gdb backtrace of it? See http://dovecot.org/bugreport.html
participants (3)
-
Fintec
-
HenkJan Wolthuis
-
Timo Sirainen