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.