First of all, I think dovecot is really fantastic and I have thanks
for all
the hard work. I think it will be the best fit for my ~5000 users
when I have it setup completely. We normally have approx 500
concurrent IMAP
connections during the day.
I am trying to convert from courier-imap to dovecot, but I have an
issue with
public namespace folders that are not writable by certain users.
Please let me
know if I need to provide more information or how I can help solve
this issue.
In courier-imap, we were able to take advantage of the maildir
structure and standard unix users/groups to allow 'decsstaff' members
to have full write access while 'decsall' members only have r/o
unless also a member of 'decsstaff':
-rw-rw-r-- 1 postlocal decsstaff 37597 May 5 23:37
/egr/mail/shared/decs/.support.In/cur/1178422658.M533373P54269.ice
drwxrwxr-x 2 postlocal decsstaff 24576 May 5 23:37
/egr/mail/shared/decs/.support.In/cur
drwxrws--- 6 postlocal decsall 4096 Apr 22 18:08
/egr/mail/shared/decs/.support.In
drwxrwsr-x 34 postlocal wheel 4096 May 1 07:23 /egr/mail/shared/decs
In short, upper directories are used to limit world access to just
one group 'decsall', and once inside, r/o world access could be used
as an anonymous substitution for 'decsall' and the group permissions
would allow writing by 'decsstaff'. I don't know how courier stores
and checks mail directory permissions, but it was aware when a user
would not be able to delete or change messages and would return a
READ-ONLY imap error when an attempt to change a message occurred
(courier returns this in the IMAP response to update mail flags to
reflect that the client wants to move to delete a mail). I
understand that imap clients will usually only set status as read or
deleted first and only try to delete an email for real on expunge,
but it seems dovecot does not try to detect if a message is
modifyable before it is too late for the user to find out. What
happens is a user appears to be able to mark messages read, move them
to another folder, or delete them (another way of moving to another
folder eg. Trash). The user is clueless that the changes will not
occur, and only finds out later when they reload the folder to find
the messages back, or tries to expunge and get an unhelpful 'internal
error' from dovecot (I can help trace this situation if it helps, but
I think that stage should not be reached if things were working
right). My configuration has the public folder control and indexes
inside a user's home directory, so it will always be possible for
dovecot to record message status changes, however I do not think
dovecot should update the control and indexes to reflect an IMAP
operation that is not allowed to complete due to restricted
permissions on the actual email file. I suppose dovecot would have
to check the permissions on mail message files.
As a workaround, I wondered if I could apply dovecot ACLs to the
public folders to reinforce my intentions of only allowing readonly
access to certain users. If ACLs worked, I could even use it as a
viable alternative to the unix permissions on the maildir contents
and avoid using more unix groups than necessary. For most of our
shared mailboxes, there will only be a few persons with write access,
and up to a dozen people with read access, so even if I have to list
every user seperately I could. However, I have not been able to get
ACLs to do anything useful for me, and I hesitate to use the feature
to work around might be a configuration error or bug. It is also
more convenient for my migration procedure if I do not have to modify
file permissions or structure during downtime to switch to dovecot.
I am still not sure how dovecot ACLs affect the actual permissons of
dovecot processes. I have mostly tried placing a dovecot-acl file in
the maildir directory (alongside cur, tmp, new) and dovecot seems to
be reading it according to the log, however I am not getting expected
results from the ACLs. If the unix permissions allow a client to
enter 'cur' and read mails, the mail client thinks it can delete or
move them (until expunge) no matter even if I put acl entries with
only 'r' permission.
ACL questions (which might help others understand better as well):
Is a 'user=foo rl' entry supposed to remove any possible write
permissions in a maildir covered by such an ACL for user foo? If
not, shouldn't it at least enforce restrictions on the available mail
metadata which is more likely to be writable by the user?
Is it even possible for an ACL to grant additional permissions above
what is granted to a user by standard unix permissions?
Does an empty ACL equate to the exact permissions granted by unix,
and should an admin try to design an ACL to modify as little as
possible, or should the admin try to use enough acl entries to form a
complete description of the desired resulting permissions? I get the
impression that broad ACLs should be listed first, and more specific
ACLS listed below can add or remove ACL permissions applied earlier
in the file as a 'last match' case.
Should the acl plugin be able to print a summary of the resulting
permissions in the log (with mail_debug=yes) when accessing a folder
with an ACL?
A snip from logs, I generated alot today and I'm not sure which portions
would be most useful so I'll start with this:
May 6 15:20:08 gribble dovecot: IMAP(mcdouga9): acl: initializing
backend with data: vfile:/usr/local/etc/dovecot-acls
May 6 15:20:08 gribble dovecot: IMAP(mcdouga9): acl: acl username =
mcdouga9
May 6 15:20:08 gribble dovecot: IMAP(mcdouga9): acl: owner username =
May 6 15:20:08 gribble dovecot: IMAP(mcdouga9): acl vfile: Global
ACL directory: /usr/local/etc/dovecot-acls
May 6 15:20:08 gribble dovecot: IMAP(mcdouga9): Namespace:
type=public, prefix=#shared/decs/, sep=/, inbox=no, hidden=no,
subscriptions=no
May 6 15:20:08 gribble dovecot: IMAP(mcdouga9): maildir:
data=/egr/mail/shared-dovecot2/decs:CONTROL=/home/mcdouga9/Maildir/dovecot/public/control/decs:INDEX=/home/mcdouga9/Maildir/dovecot/public/indexes/decs
May 6 15:20:08 gribble dovecot: IMAP(mcdouga9): maildir:
root=/egr/mail/shared-dovecot2/decs,
index=/home/mcdouga9/Maildir/dovecot/public/indexes/decs,
control=/home/mcdouga9/Maildir/dovecot/public/control/decs, inbox=
May 6 15:20:08 gribble dovecot: IMAP(mcdouga9):
opendir(/egr/mail/shared-dovecot2/decs/tmp) failed: Permission denied
# dovecot --version
1.0.0
The reason I have so many public spaces below, is to match the existing
directory structure we setup for courier, and also to help us keep the
directory listing more tidy since otherwise we would end up with many
folders
all under one directory. Some of them have monthly rotation and it
could get
out of hand if we did not split them up. I understand it makes
things more difficult for the global acl list at present, if I were
to use it, but I may not have any conflicting folder names at this time.
# dovecot -n
# /usr/local/etc/dovecot.conf
ssl_cert_file: /usr/local/etc/apache2/ssl/mail.egr.msu.edu.pem
ssl_key_file: /usr/local/etc/apache2/ssl/mail.egr.msu.edu.pem
login_dir: /var/run/dovecot/login
login_executable: /usr/local/libexec/dovecot/imap-login
verbose_proctitle: yes
first_valid_uid: 1000
first_valid_gid: 0
mail_location:
maildir:~/Maildir:CONTROL=%h/Maildir/dovecot/private/control:INDEX=%h/Maildir/dovecot/private/indexes
mail_debug: yes
mmap_disable: yes
maildir_copy_with_hardlinks: yes
mail_plugins: acl
mail_log_max_lines_per_sec: 0
imap_client_workarounds: delay-newmail outlook-idle netscape-eoh
tb-extra-mailbox-sep
namespace:
type: public
separator: /
prefix: #shared/be/
location:
maildir:/egr/mail/shared-dovecot2/be:CONTROL=%h/Maildir/dovecot/public/control/be:INDEX=%h/Maildir/dovecot/public/indexes/be
namespace:
type: public
separator: /
prefix: #shared/cee/
location:
maildir:/egr/mail/shared-dovecot2/cee:CONTROL=%h/Maildir/dovecot/public/control/cee:INDEX=%h/Maildir/dovecot/public/indexes/cee
namespace:
type: public
separator: /
prefix: #shared/chems/
location:
maildir:/egr/mail/shared-dovecot2/chems:CONTROL=%h/Maildir/dovecot/public/control/chems:INDEX=%h/Maildir/dovecot/public/indexes/chems
namespace:
type: public
separator: /
prefix: #shared/decs/
location:
maildir:/egr/mail/shared-dovecot2/decs:CONTROL=%h/Maildir/dovecot/public/control/decs:INDEX=%h/Maildir/dovecot/public/indexes/decs
namespace:
type: public
separator: /
prefix: #shared/egr/
location:
maildir:/egr/mail/shared-dovecot2/egr:CONTROL=%h/Maildir/dovecot/public/control/egr:INDEX=%h/Maildir/dovecot/public/indexes/egr
namespace:
type: public
separator: /
prefix: #shared/me/
location:
maildir:/egr/mail/shared-dovecot2/me:CONTROL=%h/Maildir/dovecot/public/control/me:INDEX=%h/Maildir/dovecot/public/indexes/me
namespace:
type: public
separator: /
prefix: #shared/org/
location:
maildir:/egr/mail/shared-dovecot2/org:CONTROL=%h/Maildir/dovecot/public/control/org:INDEX=%h/Maildir/dovecot/public/indexes/org
namespace:
type: public
separator: /
prefix: #shared/toptest/
location:
maildir:/egr/mail/shared-dovecot2/toptest:CONTROL=%h/Maildir/dovecot/public/control/toptest:INDEX=%h/Maildir/dovecot/public/indexes/toptest
namespace:
type: public
separator: /
prefix: #shared/ugs/
location:
maildir:/egr/mail/shared-dovecot2/ugs:CONTROL=%h/Maildir/dovecot/public/control/ugs:INDEX=%h/Maildir/dovecot/public/indexes/ugs
namespace:
type: public
separator: /
prefix: #shared/vprgs/
location:
maildir:/egr/mail/shared-dovecot2/vprgs:CONTROL=%h/Maildir/dovecot/public/control/vprgs:INDEX=%h/Maildir/dovecot/public/indexes/vprgs
namespace:
type: private
separator: /
prefix: mail/
hidden: yes
namespace:
type: private
separator: /
location:
maildir:~/Maildir:CONTROL=%h/Maildir/dovecot/private/control:INDEX=%h/Maildir/dovecot/private/indexes
inbox: yes
auth default:
mechanisms: plain login
passdb:
driver: pam
userdb:
driver: passwd
socket:
type: listen
client:
path: /var/spool/postfix/private/auth
user: postfix
group: postfix
master:
plugin:
acl: vfile:/usr/local/etc/dovecot-acls
Thanks.
