[Mailman-Developers] Who is the "site administrator"?

[Barry Warsaw]

On Jan 24, 2015, at 04:05 PM, Andrew Stuart wrote:

>The main thing I’m looking for is whether there is an authorisation concept
>that operates at a higher level than the list.

No, there isn't[*].

>I wonder is there the concept of some sort of “special” mailing list that is
>different or hidden or privileged in some way? There is a reference in the
>documentation to a “site list” but I coudn’t find much more about it. If
>there is a “special” list then maybe site wide user priveleges can be stored
>against it.

There is no site list in Mailman 3.

>I can see there is a site_owner in the Mailman config file although this just
>seems to be an email address to get bounces in certain circumstances, is it
>used for anything?

Just for bounces, as you've discovered.

>Well I read the discussion thread.  I had no idea so much previous thinking
>had gone into this.  Funny that there was so much discussion but no-one has
>really chimed in with an opinion about how I’ve built the authentication
>proxy - maybe everyone’s gun-shy. :-)

I haven't yet had time to dig into your work - apologies for that!

>The only unresolved question for me coming out of all that is “where is it
>specified which users have access rights to carry out functions at a higher
>level than the list?”
>
>It appears that such information is not part of the Mailman core user data
>model and needs to be handled outside Mailman core i.e. at the application
>level.

This is correct.  It's the big reason why currently the API is an all-access
administrative API.  If the core was explicit in the roles an access right,
then an authenticating proxy wouldn't be necessary.

Sumana's summary is essentially correct.  There seems to be 6 (-ish) natural
roles that actors can play.  We can disregard the site administrator as that's
the person with shell access and the necessary permissions to "pop the hood"
and do anything.

Given that we have mailing lists organized into domains, it makes sense that
each mailing list have its owner, each domain have its manager, and the system
as a whole has a manager as well.  The system manager can do things like
create new domains, install global bans, and can delegate responsibility for
domains and mailing lists to others.

For a site with multiple domains, a domain manager can create lists within
that domain and delegate management of mailing lists to the owners of those
lists.  List owners can change any setting, and can delegate moderation
privileges to list moderators.

Users can manage their own subscriptions, and the various settings associated
with their memberships.

In Mailman 3, this breakdown is purely conceptual, and as you've seen there
has been heated discussion in the past.  I'm open to rebooting that.  I have
strong opinions but am willing to be persuaded, especially if there is code to
back it up. :)

>Personally I’d store such user information inside the Mailman core data
>model. Things start to look weird when application X has a different
>mechanism for deciding who can do admin tasks to application Y.  Maintaining
>such info outside the core also calls for user database synchronisation which
>would be good to avoid. But I don’t really mind I’m just trying to get a
>secure way of deciding which users to allow to do higher-than-list-level
>functions.

Alternatively, once the core bakes in these assumptions, then it becomes very
difficult for other tools to experiment with other ways of doing it, or
integrating the decision making with other external systems.

I've been of the mind that we should define a service that defines this
breakdown as interfaces and APIs.  Then we would be free to implement this as
a third party tool that peer with the core, Postorious, HK, the API proxy, and
others.  We could provide a reference implementation for those who want a
simple turnkey solution, but integrators would also be free to back those APIs
up with alternative implementations based on their specific needs.

As it turns out, the core doesn't have a lot of need for this, which is
another reason I've so far resisted tightly integrating it with the core.
Maybe we'll find some interesting uses once such a service is available
though.

>1: eliminate public access to all functions that operate higher than list
>level

>2: bake my own additional level of user authentication that defines which
>users have higher level access rights.

>3: find a cheat/workaround to store arbitrary keys against users (this my
>preferred solution)

>4: something else
>
>Option 1 drastically reduces the usefulness of the interface if only list
>level functions can be executed. Not ideal.

Agreed.

>Option 2 I would prefer to avoid - my authentication proxy doesn’t actually
>know much about Mailman at an application level - all it does is authorise
>and authenticate and pass through requests to Mailman if the user is allowed
>to do it, and reject them if not.

>Option 3: find some sort of cheat/workaround - preferablyt a way to store
>additional user information in a user profile field which allows storage of
>arbitrary keys.  Then I could stash some access control information in there
>that tells me that user X or user Y has some higher level access
>control. This would have to be do-able via the Mailman REST interface cause
>it’s the only way that I talk to the system. The ability to store arbitrary
>key/value information against a user would be the ideal outcome at this
>stage.

This is very close to the system I've envisioned, although I would make it a
separate system with a separate API.  The proxy would then talk to this API
when it needed such information.

Cheers,
-Barry

[*] There's still the moderator_password turd in the mailinglist model.  I
think I need to get rid of that now once and for all. :)