expanding allowsetacl

Bron Gondwana brong at fastmailteam.com
Thu Jun 25 21:59:19 EDT 2020

On Thu, Jun 25, 2020, at 00:57, Ricardo Signes wrote:
> Behold this commit:
> commit da8305164877735ba29b078151c70455f1aa6eea
Author: Bron Gondwana <brong at fastmail.fm>
Date:   Wed Oct 30 14:13:38 2019 +1100

    imapd: allow disabling the SETACL command
> I'm not sure what the intent here was, but I *assume* it was related to our plan to kill of the ability of users to set their own ACLs. If so, I think we need two small changes which I'd like to get out pretty soon.
>  1. relax the restriction so the admin user can still use SETACL
>  2. tighten the restriction so it also restricts DELETEACL
> That's it! Then we'll move on to rolling that out and cleaning up users' existing ACLs. I have tentatively made a task for this <https://app.liquidplanner.com/space/14822/projects/show/58761531>.
> Bron: I just want to make sure we're not stepping on work intended for something else!

So... this does also handle DELETEACL, because they both call cmd_setacl, just with different paramenters. Maybe it should be called cmd_frobacl or something.

As for allowing the admin - the way to do that is for the admin to connect to a different imapd which has no such restrictions. At least the way this is intended for use at Fastmail, it will only be on set on particular services entries rather than globally, so the `imapadmin` service won't have it set.


 Bron Gondwana, CEO, Fastmail Pty Ltd
 brong at fastmailteam.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.andrew.cmu.edu/pipermail/cyrus-devel/attachments/20200626/54404dd2/attachment.html>

More information about the Cyrus-devel mailing list