[Dovecot] Dovecot not handling r/o mailboxes completely, and problem with ACL as a workaround

[Matt Zukowski]

Adam, unfortunately I don't have an answer for you, but I'd just like to
add that we've had no luck getting dovecot's ACL working properly here
either (see my previous message: "some clarification re: ACL"). No one
responded to my original message, which leads me to suspect that the ACL
feature isn't widely used (if at all) and is therefore not fully
implemented.

P.S. Sorry Adam, that should have gone out to the list rather than to 
you personally.

Adam McDougall wrote:
> 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.
>   




This e-mail message is privileged, confidential and subject to copyright. Any unauthorized use or disclosure is prohibited. 
Le contenu du pr'esent courriel est privil'egi'e, confidentiel et soumis `a des droits d'auteur. Il est interdit de l'utiliser ou de le divulguer sans autorisation.