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

Andy Shellam andy.shellam-lists at mailnetwork.co.uk
Mon May 7 17:24:34 EEST 2007


Hi Matt,

That's disappointing to hear as I'm also hoping to get ACLs working 
(particularly for shared/public folders.)
I'll be looking into this over the coming few weeks so no doubt you'll 
be hearing more off me :)

Andy

Matt Zukowski wrote:
> 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.
>
>
>
> !DSPAM:37,463f35c4343943800472658!
>
>



More information about the dovecot mailing list