Re: [Mailman-Developers] Authorization System in Core

On 05/22/2016 12:08 AM, Harshit Bansal wrote:
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:
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.
Yes, but it would be dropped in favor of OAuth or similar.

On May 22, 2016, at 12:54 AM, Simon Hanna wrote:
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

Simon Hanna writes:
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.
Yes, but it would be dropped in favor of OAuth or similar.

On May 22, 2016, at 12:54 AM, Simon Hanna wrote:
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