[Mailman-Developers] ACL in Mailman - what's you opinion

[Barry Warsaw]

Hi benste,

On May 27, 2011, at 05:46 PM, Benedict Stein wrote:

>wacky and i discussed a few things about how to implement ACL within the
>Mailman3 parts.
>I've wrote a small Blogpost about it in
>http://benste.blogspot.com/2011/05/mailman-3-restapi-webui-acl.html
>
>just in case you want to contribute to Pro/Con list directly go to
>http://wiki.list.org/display/DEV/Pro+-+Con+ACL+in+different+Layers+%28WebUI%29

There's another way of implementing ACLs, which would be useful to explore,
and which is what I've had in the back of my mind for a while now.

First a quick review.  As you mention, I've long advocated that the core's
REST API be a full-permission, admin-only API.  The requirement here of course
is that it can really only be published over completely trusted channels, and
we've said for several years now that this means only on localhost.  As you
point out this has several advantages:

* It keeps the REST API simple
* It keeps the data model simple
* Clients have unlimited functional flexibility
* Not locked into the core's perception of permissions and security

As you rightly point out, the downside is that the core is essentially
punting, and requiring all of its clients to implement security, access, and
permissions.

In my mind, I've always thought that you could implement some middleware to
handle this, in a way that would better serve clients.  For example, if I had
some middleware that also exposed a REST API, but required authentication for
each request, it could do the permission check, filter the request as
appropriate, and forward it to the core.  Of course, responses could also be
filtered if necessary, but this would present exactly the API that clients
required.

This is appealing because it allows for pluggability and customization for
various environments, without imposing extra complexity on the core.  Here's
another use case to illustrate.

Let's say I wanted to replace Launchpad's mailing lists with Mailman 3.  Now,
Launchpad has a very rich user and permission model, involving accounts,
people, teams, OAuth, SSO, SSL, etc.  I think it would be quite difficult to
integrate Launchpad's notion of permissions into the core's model, or even to
design the core's model so that you could plug things in at every level.  It's
much more approachable to me to just hook up the user and team model to be
able to do the much easier task of determining list membership for posting
purposes.  Launchpad's own security infrastructure would limit who can do what
to the Mailman core, of course through its own web ui and API.  Launchpad
itself would essentially be the middleware filtering requests to the core
through its permission model.

Launchpad's security model would be very different from Mailman's Django web
ui's model.  It seems insurmountable to me that the core is the piece that
resolves, integrates, and allows these divergent models.

I know it's a cop-out to keep punting on security in the core, but I actually
think it's a *useful* cop-out.  For the great number of sites I see as
integrating Mailman 3 with their own web ui, they already probably have pretty
complex systems with their own permission models, and I'm leery of adding the
necessary complexity to the core for Mailman to be a client of those security
models.  For the great number of sites that will just use Mailman's Django web
ui out of the box, we can use Django's features to implement security, with
perhaps some well-placed queries into the core's API or database to determine
membership relationships.

The core's job is to deliver email.  It's existing "permission model" is just
enough to decide whether and when to do that.

As always, I'm interesting in hearing other people's opinions on this, and
will of course keep an open mind.  I'm also not against adding some minimum of
required functionality to enable this security middleware I'm thinking about.
But I also think it makes a lot of sense to keep the core as simple as
possible (but no simpler :).

Thanks for kicking off this discussion!

Cheers,
-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20110527/c1422efc/attachment.pgp>