[Dovecot] BUG(?): Incorrect responses for ACL prohibited actions
In a mailbox that has ACL restrictions on both DELETE and EXPUNGE
(i.e. no 'e' or 't' rights), I see the following:
3 UID STORE 3173 (UNCHANGEDSINCE 353) +FLAGS \deleted 3 OK Store completed.
(UID 3173 is not flagged \deleted)
[...]
6 UID EXPUNGE 1:* 6 OK Expunge completed.
(At least 1 UID is flagged \deleted in mailbox)
Shouldn't these commands be returning "NO" instead of "OK"? RFC 3501
[6.4.6] for STORE:
NO - store error: can't store that data
and RFC RFC 3501 [6.4.3] for EXPUNGE:
NO - expunge failure: can't expunge (e.g., permission denied)
Additionally, RFC 5530 [3] provides the NOPERM response code:
NOPERM
The access control system (e.g., Access Control List (ACL), see
[RFC 4314]) does not permit this user to carry out an operation,
such as selecting or creating a mailbox.
C: f select "/archive/projects/experiment-iv"
S: f NO [NOPERM] Access deniedMy reading of this is that NOPERM should be returned for ANY ACL
prohibited action, not just for selecting or creating a mailbox.
Dovecot 2.0.12 does not return NOPERM for DELETE/EXPUNGE actions (at a
minimum) that are prohibited.
Thoughts?
michael
On 10.5.2011, at 21.44, Michael M Slusarz wrote:
Clients aren't very happy about seeing NO. Also Dovecot didn't say anything changed with either of the above commands, so nothing really failed either. A "STORE +FLAGS.SILENT \Deleted" is more controversial though. Maybe that should return NO..
I'm not really sure. Maybe for EXPUNGE a NO would be okay. For flag changes it's just annoying to see clients popup pointless error messages when trying to set a \Seen flag (or \Answered flag when replying).
Also I'm not sure if Dovecot's behavior is entirely correct either here. It might be more correct that all flag changes succeed, but those flags would be session-only flag changes rather than permanent flag changes.
It's a slightly difficult subject :)
Quoting Timo Sirainen <tss@iki.fi>:
I personally don't care about +FLAGS.SILENT, since ideally people
should be using CONDSTORE/QRESYNC :) - in which case FLAGS.SILENT is
irrelevant.
But as far as the NO for a non-silent STORE, it seems that RFC 4314
[4] disagrees with you:
STORE operation SHOULD NOT fail if the user has rights to modify
at least one flag specified in the STORE, as the tagged NO
response to a STORE command is not handled very well by deployed
clients.To me, the negative inference from this statement would be: "STORE
operation SHOULD fail if the user has no rights to modify at least one
flag specified in the STORE." So I would agree with your statement
that there should not be a NO response if at least one flag is
settable, but I disagree (and RFC 4314 seems to back me up) and
believe that there should be a NO if none of the flags given can be set.
At a minimum, a NOPERM response should be thrown, or else there is no
feedback at all why the flag was not set (without parsing ACLs).
Ideally a client should disable all features not available to the user
in the UI - something I am presently working on - but that should not
eliminate the need for useful error responses in order to determine if
the action was successful.
That may be true, but if a user can't do something in a mailbox I
would rather have them be told of their limitations rather than have
them scratch their head while trying to figure out why things aren't
happening that they are explicitly (and, if failing, most likely
repeatedly) trying to do.
Alternatively, there doesn't seem to be any limitation to use NOPERM
with a NO response. Theoretically, you could issue an OK with NOPERM.
Clients are required to ignore response codes they don't recognize,
and those that do can make the determination whether any NOPERM,
regardless of status response, should be something they might be
interested in dealing with.
Discussion of session-only flags is all laid out in RFC 3501, so I can
vouch that *my* client software handles them correctly :) I can not
comment on the potential work needed on the server end.
michael
Hi,
Continuing this old thread:
On Tue, 2011-05-10 at 22:46 -0600, Michael M Slusarz wrote:
That's not the negative of it. :)
At a minimum, a NOPERM response should be thrown, or else there is no
feedback at all why the flag was not set (without parsing ACLs).
Perhaps OK [NOPERM] or some other kind of informational message about it .. But there's no way to do it with Dovecot's current API.
Also RFC 3501 recommends implementing "session flags" for flags that cannot be permanently stored. So even if user doesn't have access to set any flags, a "well behaving IMAP server" (so not Dovecot :( ) would set those flags for the duration of the current session.
Anyway, you can look at PERMANENTFLAGS reply to see if it's possible to set the flag, no need to look at ACLs.
Apparently I've tried this earlier, since there's a comment in code:
ret = acl_mailbox_right_lookup(_mail->box, ACL_STORAGE_RIGHT_EXPUNGE);
if (ret <= 0) {
/* if we don't have permission, silently return success so
users won't see annoying error messages in case their
clients try automatic expunging. */
participants (2)
-
Michael M Slusarz
-
Timo Sirainen