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

[Timo Sirainen]

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

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://dovecot.org/pipermail/dovecot/attachments/20070511/050b30b3/attachment.pgp