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

[Richard Wackerbarth]

Barry,

I do not understand why "published over completely trusted channels" "means only on localhost".
When two machines are involved, you have to be able to trust both of them, but they don't have to be the same machine.
In addition, you will need to open a secure channel. Even over public channels, signed, and possibly encrypted, messages should be sufficient as long as you don't expose the keys.

Wacky

On May 27, 2011, at 3:18 PM, Barry Warsaw wrote:

> 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
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers at python.org
> http://mail.python.org/mailman/listinfo/mailman-developers
> Mailman FAQ: http://wiki.list.org/x/AgA3
> Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/
> Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/richard%40nfsnet.org
> 
> Security Policy: http://wiki.list.org/x/QIA9