Re: [Mailman-Developers] Authorization System in Core
On 05/22/2016 12:08 AM, Harshit Bansal wrote:
Hi Simon, This is the discussion that I was referring to:
Harshit Bansal writes:
I think the "Permissions Systems" would have nothing to do with the core. It would be related to Postorius. We will have to create a style model separately in Postorius which would store the style name and the user who created it. Then only the user who has created the style would be granted the permission to edit it.
Stephen J. Turnbull wrote:
Then there is no *permissions* system! For example, one project last year created a Javascript client -- that would completely bypass the "permissions" system as you describe it. You could imagine that style changes are a "friendly users" feature, and so the "style owner" system would be a *safety* feature of the Postorius UI rather than an *authorization* feature of styles. But in an enterprise context (eg, a virtual hosting service), I'm sure that users will think of it as an authorization system. While at present it seems unlikely that there would be multiple interfaces on one hosting service, you never know what users will do[1]. Also, it would not be obvious to somebody who installed the node.js Mailman client that they are likely bypassing "security" as documented in the typical Mailman manuals and tutorials that you would find on the web.
Thanks, Harshit Bansal
Hi, Earlier, while discussing the permission system for manging styles, it was decided that the permissions system should be enforced in the core rather than in the postorius since otherwise it can be bypassed(deliberately or undeliberately). But one thing that I think I forgot to discuss was that currently there is no authorisation system in the core and now I am unable to figure out that how could the permissions be enforced in the core without an authorisation system. Should I workout an authorisation system for the core first or enforce permissions in postorius only?
After reading this and your proposal, I'm wondering why you want to add the permission system in postorius.
You are storing the styles in core, and grant permissions based on list/domain/site ownerships. All this information is in core.
Currently mailmanclient exposes everything, not caring about permissions. You have admin rights, whoever uses mailmanclient has to manage access on their own.
We currently have @list_moderator_required that we use in postorius. We are not doing anything with domain or site owners, but they should be pretty easy to implement.
While in theory it would be possible to enforce permissions in core about who is allowed to call specific rest calls, this would require a lot of changes. I'm not sure we want to go this way.
There are some things in core, that suggest that this might come sometime. (Users have passwords and you can authenticate them) But I guess this is somewhat legacy and will be dropped sometime in the future.
Simon Hanna writes:
While in theory it would be possible to enforce permissions in core about who is allowed to call specific rest calls, this would require a lot of changes. I'm not sure we want to go this way.
Mailman is used in a lot of enterprises contexts, where the system administrators would like to distribute the components across various hosts. Also, the Mailman subscription database itself may be sensitive. Eventually we're going to have to face this issue, although maybe not now.
For the styles, I don't think they're particularly sensitive. As I indicated in the quoted passage, we can simply interpret the "permissions" as a way to protect users from doing stupid things rather than an authn/authz system. In that case it's fine to do it in Postorius.
There are some things in core, that suggest that this might come sometime. (Users have passwords and you can authenticate them) But I guess this is somewhat legacy and will be dropped sometime in the future.
Yes, but it would be dropped in favor of OAuth or similar.
On May 22, 2016, at 12:54 AM, Simon Hanna wrote:
While in theory it would be possible to enforce permissions in core about who is allowed to call specific rest calls, this would require a lot of changes. I'm not sure we want to go this way.
I've resisted this for a long time, and I may continue to do so :).
I definitely consider the current REST API a privileged, administrative API for integrating known, trusted components. It should never be published on any public IP address. This isn't going to change.
A while back, Andrew Stuart wrote an authenticating proxy server he called "mailmania"[1] which does exactly as Simon proposes above. It authenticates users and maps their roles to allowed REST calls. It could be exposed on a public IP and used to script the core.
I'd like to either promote mailmania to a official subproject, or fork it, clean it up, and offer something much like it, either as a subproject (likely at first) or as an optional component of the core. Andrew has donated this to the FSF so we can use what we want, but I think he doesn't have time these days to develop it. I'd like to come up with a better name :).
Anyway, that's the direction I think such a permission system should go in.
Cheers, -Barry
You are most welcome to do as you wish with Mailmania, rename, fork, rebuild, whatever - I’m not precious about it - it is owned by the FSF and GPL licensed. It might be just a good “first try” and point the way to a better solution.
It certainly would benefit from a cleanup from a more experienced Python developer than me - whilst I did everything I could to make it consistent I have no doubt much could be done to improve it.
As Barry says, Mailmania puts a server layer in front of the Mailman REST API that allows authenticated public access to the Mailman REST server. It uses the Mailman conceptual authorisation model and implements that as a concrete set of authorisation rules.
It also includes an unfinished solution for archiving inbound mail to sqlite for full text indexing and integration with Apache Tika for extraction of text from documents attached to emails.
I apologise for effectively having abandoned it but I would say it is (or was last I looked) fully working with over 700 tests. I just don’t have time to fit it in to everything in life right now..
If anyone does want to do any work on it I’ll do my level best to help them get it running, understand it and problem solve any issues.
I’m working on other stuff but still watching this list so I’ll try to respond ASAP to any questions….
thanks
as
participants (4)
-
Andrew Stuart
-
Barry Warsaw
-
Simon Hanna
-
Stephen J. Turnbull