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

[Adam McDougall]

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:
  
  1. 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.
  
  2. 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.
  
  3. 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.