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.