[Dovecot] Dovecot not handling r/o mailboxes completely, and problem with ACL as a workaround
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.
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.
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!
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 location: maildir:/egr/mail/shared-dovecot2/vprgs:CONTROL=%h/Maildir/dovecot/public/c ontrol/vprgs:INDEX=%h/Maildir/dovecot/public/indexes/vprgs namespace: type: private separator: / prefix: mail/ hidden: yes
plugin: acl: vfile:/usr/local/etc/dovecot-acls
I use shared folders. I posted a while back about my setup. There have been a few changelogs since then concerning ACLs. My setup might be whacked but it still continues to work. The simplest example I have is root mail.
I have mail folders
drwxrwx--- 4 rootmail users /home/services/mail/rootmail/Maildir drwxrwx--- 4 rootmail users ../.RootmailFolder drwxrwx--- 4 rootmail users ../.RootmailFolder.general
To get around ACL plugins downside of being unaware of namespaces I create
a "RootmailFolder" underneath Maildir. No one else probably (hopefully) will
have a folder named that. If they did then the permissions in the ACL
plug-in directory would override "owner permissions". Were that to happen
then you could just put a dovecot-acl file in the user's directory to
compensate though this is a fuzzy part... this used to work but I haven't
needed to test it so I don't know if it does still.
I then created a general folder under that. I have a sieve script which pumps all mail into the general folder. So this is rootmail's "inbox". I did this as a workaround.
<might not be needed nor work anymore>
If you actually want a user 'rootmail' to use an imap client and log into their mailbox then you would create a file
/home/services/mail/rootmail/Maildir/dovecot-acl /home/services/mail/rootmail/Maildir/.RootmailFolder/dovecot-acl /home/services/mail/rootmail/Maildir/.RootmailFolder.general/dovecot-acl
all the files contain:
user=rootmail lrwstie
To use the ACL plug-in files must be create in this directory:
plugin: acl: vfile:/usr/local/etc/dovecot-acls
so I have (using your path) files:
/usr/local/etc/dovecot-acls/RootmailFolder /usr/local/etc/dovecot-acls/RootmailFolder.general
These files contain
user=jhorner lrwstie
My namespace is setup as:
namespace public { separator = . prefix = ROOTMAIL. location = maildir:/home/services/mail/rootmail/Maildir:CONTROL=%h/shared-settings/rootmail/control:INDEX=%h/shared-settings/rootmail/index hidden = no inbox = no }
Everyone can see the namespace but no one but me can access the namespace because RootmailFolder is only accessible by me. Those who do try to access a forbidden folder get a curt techie error. However, most clients do not show the namespace because there aren't any folders underneath the namespace that are accessible so this is not a problem for me.
I also have a COMPANY share setup similarly. However there are many many folders underneath this share and different people can access different folders and I accomplish that using the ACL plug-in similar to above.
I used to use Courier and I was able to duplicate shared folders via the ACL plug-in though the folders are now one level deeper, i.e. ROOTMAIL/RootmailFolders/general as opposed to ROOTMAIL/general (namespace/foldername). Some users did complain. Oh well... most are still breathing.
Jim
I would just add to this that simply putting a dovecot-acl file in a shared folder with "user=<username> <permissions>" does work just fine for us (without the complicated setup described below). Our problem is that group-based restrictions don't work at all (i.e. "group=<groupname> <permissions>", as described in the manual).
I'm also trying to figure out what the force-group ACL identifier is supposed to mean.
.... I gotta stop hitting "reply" for this list. I keep accidentally sending messages to the original authors rather than to the mailing list :)
Jim Horner wrote:
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 location: maildir:/egr/mail/shared-dovecot2/vprgs:CONTROL=%h/Maildir/dovecot/public/c ontrol/vprgs:INDEX=%h/Maildir/dovecot/public/indexes/vprgs namespace: type: private separator: / prefix: mail/ hidden: yes
plugin: acl: vfile:/usr/local/etc/dovecot-acls
I use shared folders. I posted a while back about my setup. There have been a few changelogs since then concerning ACLs. My setup might be whacked but it still continues to work. The simplest example I have is root mail.
I have mail folders
drwxrwx--- 4 rootmail users /home/services/mail/rootmail/Maildir drwxrwx--- 4 rootmail users ../.RootmailFolder drwxrwx--- 4 rootmail users ../.RootmailFolder.general
To get around ACL plugins downside of being unaware of namespaces I create a "RootmailFolder" underneath Maildir. No one else probably (hopefully) will have a folder named that. If they did then the permissions in the ACL
plug-in directory would override "owner permissions". Were that to happen then you could just put a dovecot-acl file in the user's directory to compensate though this is a fuzzy part... this used to work but I haven't needed to test it so I don't know if it does still.I then created a general folder under that. I have a sieve script which pumps all mail into the general folder. So this is rootmail's "inbox". I did this as a workaround.
<might not be needed nor work anymore>
If you actually want a user 'rootmail' to use an imap client and log into their mailbox then you would create a file
/home/services/mail/rootmail/Maildir/dovecot-acl /home/services/mail/rootmail/Maildir/.RootmailFolder/dovecot-acl /home/services/mail/rootmail/Maildir/.RootmailFolder.general/dovecot-acl
all the files contain:
user=rootmail lrwstie
To use the ACL plug-in files must be create in this directory:
plugin: acl: vfile:/usr/local/etc/dovecot-acls
so I have (using your path) files:
/usr/local/etc/dovecot-acls/RootmailFolder /usr/local/etc/dovecot-acls/RootmailFolder.general
These files contain
user=jhorner lrwstie
My namespace is setup as:
namespace public { separator = . prefix = ROOTMAIL. location = maildir:/home/services/mail/rootmail/Maildir:CONTROL=%h/shared-settings/rootmail/control:INDEX=%h/shared-settings/rootmail/index hidden = no inbox = no }
Everyone can see the namespace but no one but me can access the namespace because RootmailFolder is only accessible by me. Those who do try to access a forbidden folder get a curt techie error. However, most clients do not show the namespace because there aren't any folders underneath the namespace that are accessible so this is not a problem for me.
I also have a COMPANY share setup similarly. However there are many many folders underneath this share and different people can access different folders and I accomplish that using the ACL plug-in similar to above.
I used to use Courier and I was able to duplicate shared folders via the ACL plug-in though the folders are now one level deeper, i.e. ROOTMAIL/RootmailFolders/general as opposed to ROOTMAIL/general (namespace/foldername). Some users did complain. Oh well... most are still breathing.
Jim
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.
What are the directory and file permissions of your shared folder, and do your <permissions> cause an increase or reduction of permissions compared to the dir and file permissions, or some of both?
On Mon, May 07, 2007 at 02:47:40PM -0400, Matt Zukowski wrote:
I would just add to this that simply putting a dovecot-acl file in a shared folder with "user=<username> <permissions>" does work just fine for us (without the complicated setup described below). Our problem is that group-based restrictions don't work at all (i.e. "group=<groupname> <permissions>", as described in the manual).
I'm also trying to figure out what the force-group ACL identifier is supposed to mean.
.... I gotta stop hitting "reply" for this list. I keep accidentally sending messages to the original authors rather than to the mailing list :)
On 5/7/2007 Adam McDougall (mcdouga9@egr.msu.edu) wrote:
.... I gotta stop hitting "reply" for this list. I keep accidentally sending messages to the original authors rather than to the mailing list
:)
I know, I hate that...
You can at least set yours up so that when someone replies to one of your messages, it goes to the list.
I wish TBird had proper support for Reply-To-List...
--
Best regards,
Charles
On 5/7/2007 Charles Marcus (CMarcus@Media-Brokers.com) wrote:
You can at least set yours up so that when someone replies to one of your messages, it goes to the list.
Wups, meant to include a link:
http://dovecot.org/cgi-bin/mailman/listinfo/dovecot
--
Best regards,
Charles
The shared mailbox and all its files and subdirectories are owned by the 'dovecot' user and by the 'domain users' group that all users belong to. The ACL restrictions cause a reduction (i.e. more fine-grained constraint) in privileges. In other words, at the system-file level, everyone can read the directory/files, but at the ACL level, only members of some particular list of groups should be able to read them.
And as I said, the user=<username> constraint seems to work fine, but group=<groupname> does not. It looks like the group=<groupname> constraint just never matches anyone. So I might have group=admins and "joeblow" is in group admins, but Dovecot thinks that he isn't.
Adam McDougall wrote:
What are the directory and file permissions of your shared folder, and do your <permissions> cause an increase or reduction of permissions compared to the dir and file permissions, or some of both?
On Mon, May 07, 2007 at 02:47:40PM -0400, Matt Zukowski wrote:
I would just add to this that simply putting a dovecot-acl file in a shared folder with "user=<username> <permissions>" does work just fine for us (without the complicated setup described below). Our problem is that group-based restrictions don't work at all (i.e. "group=<groupname> <permissions>", as described in the manual).
I'm also trying to figure out what the force-group ACL identifier is supposed to mean.
.... I gotta stop hitting "reply" for this list. I keep accidentally sending messages to the original authors rather than to the mailing list :)
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.
Thanks for the clarification, I got around to testing the configuration you claim to use, but unfortunately I cannot get an ACL to have any affect on the mailbox access :( Can you tell me what acl flags you are restricting to (rl, etc) and what actual affect that has on the mail client in terms of behavior when attempting to perform an unallowed action?
I get this in the log:
May 10 15:46:58 gribble dovecot: IMAP(mcdouga9): acl: initializing backend with data: vfile:/usr/local/etc/dovecot-acls May 10 15:46:58 gribble dovecot: IMAP(mcdouga9): acl: acl username = mcdouga9 May 10 15:46:58 gribble dovecot: IMAP(mcdouga9): acl: owner username = mcdouga9 May 10 15:46:58 gribble dovecot: IMAP(mcdouga9): acl vfile: Global ACL directory: /usr/local/etc/dovecot-acls May 10 15:46:58 gribble dovecot: IMAP(mcdouga9): acl vfile: reading file /egr/mail/shared-dovecot2/decs/.support.In/dovecot-acl
# ls -ld .support.In drwxrws--- 5 postlocal decsall 4096 May 9 12:55 .support.In # ls -ld .support.In/cur drwxrwxr-x 2 postlocal decsstaff 8192 Apr 24 12:47 .support.In/cur # ls -ld .support.In/cur/1177428192.M918738P11081.zee -rw-rw-r-- 1 postlocal decsstaff 2904 Apr 24 11:23 .support.In/cur/1177428192.M918738P11081.zee
mcdouga9 is in decsstaff, which has full write permission to the directory and file.
I have inside that dovecot-acl: user=mcdouga9 rl group-override=wheel
I tried just user=mcdouga9 rl first, no effect, added group-override=wheel (mcdouga9 is a member of wheel) and restarted thunderbird, still seem to have full access to the mailbox. Argh.
On Tue, May 08, 2007 at 02:36:24PM -0400, Matt Zukowski wrote:
The shared mailbox and all its files and subdirectories are owned by the 'dovecot' user and by the 'domain users' group that all users belong to. The ACL restrictions cause a reduction (i.e. more fine-grained constraint) in privileges. In other words, at the system-file level, everyone can read the directory/files, but at the ACL level, only members of some particular list of groups should be able to read them.
And as I said, the user=<username> constraint seems to work fine, but group=<groupname> does not. It looks like the group=<groupname> constraint just never matches anyone. So I might have group=admins and "joeblow" is in group admins, but Dovecot thinks that he isn't.
Adam McDougall wrote:
What are the directory and file permissions of your shared folder, and do your <permissions> cause an increase or reduction of permissions compared to the dir and file permissions, or some of both? On Mon, May 07, 2007 at 02:47:40PM -0400, Matt Zukowski wrote:
I would just add to this that simply putting a dovecot-acl file in a shared folder with "user=<username> <permissions>" does work just fine for us (without the complicated setup described below). Our problem is that group-based restrictions don't work at all (i.e. "group=<groupname> <permissions>", as described in the manual). I'm also trying to figure out what the force-group ACL identifier is supposed to mean. .... I gotta stop hitting "reply" for this list. I keep accidentally sending messages to the original authors rather than to the mailing list :)
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.
On Tue, 2007-05-08 at 14:36 -0400, Matt Zukowski wrote:
The shared mailbox and all its files and subdirectories are owned by the 'dovecot' user and by the 'domain users' group that all users belong to.
dovecot user should never own anything at all in the filesystem. http://wiki.dovecot.org/UserIds http://wiki.dovecot.org/VirtualUsers
And as I said, the user=<username> constraint seems to work fine, but group=<groupname> does not. It looks like the group=<groupname> constraint just never matches anyone.
They don't. Groups aren't supported currently.
I have an update, I realize now that my ACL is working, however applying the ACL still does nothing to improve the original problem that dovecot doesn't seem to communicate permission failures to the client, which allows the client to become out of sync with reality on the server.
I'm really not sure how dovecot might currently determine if a folder is read only on disk, because there seems to be some handling for that case in the code. Perhaps if I knew what part of the code (or an explanation) of why it thinks a folder is not writable, I could use that to my advantage and try to make folders look more "read only" on disk.
On Sun, May 06, 2007 at 09:34:28PM -0400, 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.
<snip> 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.
<snip portion about ACLs>
# 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.
On Sun, 2007-05-06 at 21:34 -0400, Adam McDougall wrote:
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
Looks like Dovecot never returns maildir mailbox as READ-ONLY. So, your issues are:
Dovecot doesn't give an error when a flag is changed for mails. This is intentional, because otherwise you'd keep seeing "mailbox is read-only" errors all the time when reading mails (because clients keep setting the \Seen flag). Besides you're using a per-user index directory so the flag changes actually are saved.
EXPUNGE gives an internal error because it discovers too late that it can't unlink() the maildir file. This is a problem.. Even worse, you can't recover from it without deleting dovecot.index.log file. This should have two fixes:
If Dovecot ever notices that it can't unlink() a file, it should recover itself from it without giving internal errors. That would probably mean that the expunged message shows up as a new message. I'll see if I can get this fixed for v1.1.
It should treat the maildir as READ-ONLY so the EXPUNGE command is never written into dovecot.index.log in the first place. Fixed: http://dovecot.org/list/dovecot-cvs/2007-May/008734.html
- EXPUNGE silently ignores no-permissions error. I'm not sure if this is good or not. In any case it shouldn't give an error if there are no messages with \Deleted flag, but perhaps it should give an error if there are.. Some clients do automatic expunges, so it would be annoying to see error messages constantly about it. I won't change this in v1.0 branch, but perhaps in v1.1.
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.
ACL plugin makes flag changes and expunges also fail silently.
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?
Yes.
Is it even possible for an ACL to grant additional permissions above what is granted to a user by standard unix permissions?
No.
Does an empty ACL equate to the exact permissions granted by unix,
No. It means "no permissions".
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.
No comments about that, except that user=x always overrides group=y in the file. I'm not sure if the order matters within group= lines, probably yes. Then again groups aren't actually working at all currently (the code supports them, but there's no way to list user's groups currently).
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?
Maybe. Not that high priority and I'm not sure if it's that easy to implement.
On Fri, May 11, 2007 at 03:41:50PM +0300, Timo Sirainen wrote:
On Sun, 2007-05-06 at 21:34 -0400, Adam McDougall wrote:
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
Looks like Dovecot never returns maildir mailbox as READ-ONLY. So, your issues are:
Dovecot doesn't give an error when a flag is changed for mails. This is intentional, because otherwise you'd keep seeing "mailbox is read-only" errors all the time when reading mails (because clients keep setting the \Seen flag). Besides you're using a per-user index directory so the flag changes actually are saved.
EXPUNGE gives an internal error because it discovers too late that it can't unlink() the maildir file. This is a problem.. Even worse, you can't recover from it without deleting dovecot.index.log file. This should have two fixes:
If Dovecot ever notices that it can't unlink() a file, it should recover itself from it without giving internal errors. That would probably mean that the expunged message shows up as a new message. I'll see if I can get this fixed for v1.1.
It should treat the maildir as READ-ONLY so the EXPUNGE command is never written into dovecot.index.log in the first place. Fixed: http://dovecot.org/list/dovecot-cvs/2007-May/008734.html
Thanks for addressing these issues. I applied this patch and it is a good improvement; I no longer get internal errors, and it has the effect of making thunderbird _appear_ to be able to completely delete an email because dovecot records the deleted flag and ignores the expunge, but mutt can see the messages marked deleted and does print to my screen that the mailbox is readonly when I try to expunge. So thunderbird with dovecot doesn't reflect the readonly warning that courier gives when trying to mark a message deleted, but that is probably acceptable to me since it looks like it is more beneficial for me to use ACLs. I would rather use ACLs so that "deleted" messages reappear on their own, rather than worry about users "deleting" shared mail and requiring me to erase their dovecot metadata incase they changed their mind (and don't want to use something besides thunderbird to fix it).
I've also noticed that as soon as I enable the acl plugin, clients no longer have any access at all to shared mailboxes unless a dovecot-acl file is used to give them access previously granted by the file permissions. This might be worth noting in the documentation (if it is expected) so a person doesn't turn on the acl plugin without being aware of the consequences. I do appreciate that it works that way, so I will not forget to apply an acl.
- EXPUNGE silently ignores no-permissions error. I'm not sure if this is good or not. In any case it shouldn't give an error if there are no messages with \Deleted flag, but perhaps it should give an error if there are.. Some clients do automatic expunges, so it would be annoying to see error messages constantly about it. I won't change this in v1.0 branch, but perhaps in v1.1.
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.
ACL plugin makes flag changes and expunges also fail silently.
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?
Yes.
Is it even possible for an ACL to grant additional permissions above what is granted to a user by standard unix permissions?
No.
Does an empty ACL equate to the exact permissions granted by unix,
No. It means "no permissions".
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.
No comments about that, except that user=x always overrides group=y in the file. I'm not sure if the order matters within group= lines, probably yes. Then again groups aren't actually working at all currently (the code supports them, but there's no way to list user's groups currently).
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?
Maybe. Not that high priority and I'm not sure if it's that easy to implement.
participants (6)
-
Adam McDougall
-
Andy Shellam
-
Charles Marcus
-
Jim Horner
-
Matt Zukowski
-
Timo Sirainen