[Dovecot] BUG(?): Incorrect responses for ACL prohibited actions

[Michael M Slusarz]

Quoting Timo Sirainen <tss at iki.fi>:

> On 10.5.2011, at 21.44, Michael M Slusarz wrote:
>
>> 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:
>
> 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 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.

>> 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 denied
>>
>> My 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.
>
> 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).

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.

> 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 :)

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