Who is the "site administrator"?
Is this defined in any way?
Is there any concept that a given Mailman user has “site admin rights”?
Or is the concept of the “site administrator” not realised in the application and just considered to be someone with operating system level access to the system that Mailman is running on?
thanks
On 2015-01-23, 7:12 PM, Andrew Stuart wrote:
Is this defined in any way?
Is there any concept that a given Mailman user has “site admin rights”?
Or is the concept of the “site administrator” not realised in the application and just considered to be someone with operating system level access to the system that Mailman is running on?
In Mailman 2, there's no admin "users" in a typical sense but the site administrator is someone who knows the global password for a site and/or has shell access. The global password lets you log in as an admin to any list, and depending on your settings may let you do things like create and delete lists. And yes, it's really just one shared password
In Mailman 3 there's a much more nuanced user system and you can have users with site privileges (and there's no longer a need to share passwords).
Terri
you can have users with site privileges
I had a look at the data model but couldn’t see this. Would you mind please pointing me in the direction of where user site privilege information is stored?
I can see that there is the concept of “Rosters” but rosters seem to apply to lists and not at a higher level i.e. as far as I can see there’s no way to apply a roster to the system rather than to a list.
The main thing I’m looking for is whether there is an authorisation concept that operates at a higher level than the list.
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.
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?
as
On 24 Jan 2015, at 3:13 pm, Terri Oda <terri@toybox.ca> wrote:
On 2015-01-23, 7:12 PM, Andrew Stuart wrote:
Is this defined in any way?
Is there any concept that a given Mailman user has “site admin rights”?
Or is the concept of the “site administrator” not realised in the application and just considered to be someone with operating system level access to the system that Mailman is running on?
In Mailman 2, there's no admin "users" in a typical sense but the site administrator is someone who knows the global password for a site and/or has shell access. The global password lets you log in as an admin to any list, and depending on your settings may let you do things like create and delete lists. And yes, it's really just one shared password
In Mailman 3 there's a much more nuanced user system and you can have users with site privileges (and there's no longer a need to share passwords).
Terri
Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/andrew.stuart%40s...
Security Policy: http://wiki.list.org/x/QIA9
On 2015-01-23, 9:05 PM, Andrew Stuart wrote:
you can have users with site privileges
I had a look at the data model but couldn’t see this. Would you mind please pointing me in the direction of where user site privilege information is stored?
I'm not sure the concept is visible in Mailman Core, but I'm pretty sure it's in Postorius.
(And if you're bored, you can look back in the archives to the huge discussion we had about unifying the user data store... ;) )
you can look back in the archives to the huge discussion we had about unifying the user data store..
Is there search to find that discussion or do I have to manually review all the threads? Any idea what year it was in?
thanks
On 24 Jan 2015, at 4:16 pm, Terri Oda <terri@toybox.ca> wrote:
On 2015-01-23, 9:05 PM, Andrew Stuart wrote:
you can have users with site privileges
I had a look at the data model but couldn’t see this. Would you mind please pointing me in the direction of where user site privilege information is stored?
I'm not sure the concept is visible in Mailman Core, but I'm pretty sure it's in Postorius.
(And if you're bored, you can look back in the archives to the huge discussion we had about unifying the user data store... ;) )
The searchable archives are at http://www.mail-archive.com/mailman-developers%40python.org/ . (Linked to from https://mail.python.org/mailman/listinfo/mailman-developers but I know that's a big chunk of text.) (Have I mentioned I cannot wait for HyperKitty and its built-in search?) -Sumana
On 01/24/2015 08:08 AM, Andrew Stuart wrote:
you can look back in the archives to the huge discussion we had about unifying the user data store..
Is there search to find that discussion or do I have to manually review all the threads? Any idea what year it was in?
thanks
On 24 Jan 2015, at 4:16 pm, Terri Oda <terri@toybox.ca> wrote:
On 2015-01-23, 9:05 PM, Andrew Stuart wrote:
you can have users with site privileges
I had a look at the data model but couldn’t see this. Would you mind please pointing me in the direction of where user site privilege information is stored?
I'm not sure the concept is visible in Mailman Core, but I'm pretty sure it's in Postorius.
(And if you're bored, you can look back in the archives to the huge discussion we had about unifying the user data store... ;) )
Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/sumanah%40panix.c...
Security Policy: http://wiki.list.org/x/QIA9
-- Sumana Harihareswara http://brainwane.net
On 2015-01-24, 5:08 AM, Andrew Stuart wrote:
you can look back in the archives to the huge discussion we had about unifying the user data store..
Is there search to find that discussion or do I have to manually review all the threads? Any idea what year it was in?
The data store discussion was I think two years ago around the time of pycon. I started it with a thread entitled "Architecture for extra profile info"
https://mail.python.org/pipermail/mailman-developers/2013-April/022852.html
(As Sumana says, mail-archive is usually the best bet for searching the mailman archives. I searched locally, though.)
But I'm serious that it's only worth reading if you're incredibly bored. It became a huge architecture discussion that only ended on the lists with an "agree to disagree." (and I got bombarded with further comments about it on IRC for months after the list discussion ended, so I'm actually kind of still cranky about it.)
I think it's still a thing we need to look in to more seriously, but be warned that it's a topic folk have been passionate about in the past, to the point where progress was not made. On the other hand, one of the people involved in that discussion has moved on to other things and the rest of us do collaborative work together more frequently, so it might be easier to reach a solution now.
Terri
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. :-)
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.
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.
My options are:
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. 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. Option 4: - other ideas?
Does anyone know if there is a way to do Option 3 currently?
as
On 25 Jan 2015, at 7:37 am, Terri Oda <terri@toybox.ca> wrote:
On 2015-01-24, 5:08 AM, Andrew Stuart wrote:
you can look back in the archives to the huge discussion we had about unifying the user data store..
Is there search to find that discussion or do I have to manually review all the threads? Any idea what year it was in?
The data store discussion was I think two years ago around the time of pycon. I started it with a thread entitled "Architecture for extra profile info"
https://mail.python.org/pipermail/mailman-developers/2013-April/022852.html
(As Sumana says, mail-archive is usually the best bet for searching the mailman archives. I searched locally, though.)
But I'm serious that it's only worth reading if you're incredibly bored. It became a huge architecture discussion that only ended on the lists with an "agree to disagree." (and I got bombarded with further comments about it on IRC for months after the list discussion ended, so I'm actually kind of still cranky about it.)
I think it's still a thing we need to look in to more seriously, but be warned that it's a topic folk have been passionate about in the past, to the point where progress was not made. On the other hand, one of the people involved in that discussion has moved on to other things and the rest of us do collaborative work together more frequently, so it might be easier to reach a solution now.
Terri
Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/andrew.stuart%40s...
Security Policy: http://wiki.list.org/x/QIA9
On 01/24/2015 12:05 AM, Andrew Stuart wrote:
you can have users with site privileges
I had a look at the data model but couldn’t see this. Would you mind please pointing me in the direction of where user site privilege information is stored?
I can see that there is the concept of “Rosters” but rosters seem to apply to lists and not at a higher level i.e. as far as I can see there’s no way to apply a roster to the system rather than to a list.
The main thing I’m looking for is whether there is an authorisation concept that operates at a higher level than the list.
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.
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?
as
On 24 Jan 2015, at 3:13 pm, Terri Oda <terri@toybox.ca> wrote:
On 2015-01-23, 7:12 PM, Andrew Stuart wrote:
Is this defined in any way?
Is there any concept that a given Mailman user has “site admin rights”?
Or is the concept of the “site administrator” not realised in the application and just considered to be someone with operating system level access to the system that Mailman is running on?
In Mailman 2, there's no admin "users" in a typical sense but the site administrator is someone who knows the global password for a site and/or has shell access. The global password lets you log in as an admin to any list, and depending on your settings may let you do things like create and delete lists. And yes, it's really just one shared password
In Mailman 3 there's a much more nuanced user system and you can have users with site privileges (and there's no longer a need to share passwords).
Terri
Just yesterday I spoke with Barry and straightened out my own understanding of the privilege levels within Mailman. Here's the hierarchy as I understand it (the first level has the most power and each successive level has less power):
site administrator - has command-line (shell) access to the machine. (The website's system administrator, usually.) Has ultimate power! Can invoke "mailman stop", for instance, to stop mailman services.
Mailman administrator - does not have command line access to the machine, but can use the web interface to change everything within the Mailman installation on that site (that is, can do anything Postorius lets you!). Can create, change, and delete domains, lists, users, and so on.
domain administrator - Any given list belongs to 1 and only 1 domain, which correlates to an actual internet domain name, such as mozilla.org. A domain administrator can create, change/administer, and delete lists. If you set up multiple domains, you can, e.g., have one domain administrator who has power over the lists at the 70 lists at example.com, and another domain administrator for the 40 lists at example.org.
list administrator - can change list settings such as preferred language, digest threshold, footer, etc., and moderate messages, manage users, etc.
list moderator - cannot change the list's settings as a list administrator could, but can allow/reject messages on moderated lists or that trip certain rules, approve subscriptions, ban users, etc.
user - can change their own user preferences
I do not know where all this is laid out in the code, though. And I am totally willing to be told I have gotten the nomenclature wrong!
Sumana Harihareswara http://brainwane.net
Having dug around the models and data structures a bit I am wondering if some of some of these constructs are not Mailman constructs but Postorius constructs, which is to say, third party application level contstructs rather than Mailman core constructs.
Specifically the ones you refer to “domain administrator” and “mailman administrator” don’t seem to be represented in the Mailman core code. Perhaps I’m wrong of course, I’ve just done a little ham fisted glancing over the code but so far I can’t see how a user would get to become “domain administrator” or “mailman administrator”.
Which is fine of course - no problem with these being application level constructs - I’m just trying to understand because I’m writing some authorisation code and I need to know how to authorise a user to the correct level of their privilege.
thanks
as
On 24 Jan 2015, at 11:31 pm, Sumana Harihareswara <sumanah@panix.com> wrote:
On 01/24/2015 12:05 AM, Andrew Stuart wrote:
you can have users with site privileges
I had a look at the data model but couldn’t see this. Would you mind please pointing me in the direction of where user site privilege information is stored?
I can see that there is the concept of “Rosters” but rosters seem to apply to lists and not at a higher level i.e. as far as I can see there’s no way to apply a roster to the system rather than to a list.
The main thing I’m looking for is whether there is an authorisation concept that operates at a higher level than the list.
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.
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?
as
On 24 Jan 2015, at 3:13 pm, Terri Oda <terri@toybox.ca> wrote:
On 2015-01-23, 7:12 PM, Andrew Stuart wrote:
Is this defined in any way?
Is there any concept that a given Mailman user has “site admin rights”?
Or is the concept of the “site administrator” not realised in the application and just considered to be someone with operating system level access to the system that Mailman is running on?
In Mailman 2, there's no admin "users" in a typical sense but the site administrator is someone who knows the global password for a site and/or has shell access. The global password lets you log in as an admin to any list, and depending on your settings may let you do things like create and delete lists. And yes, it's really just one shared password
In Mailman 3 there's a much more nuanced user system and you can have users with site privileges (and there's no longer a need to share passwords).
Terri
Just yesterday I spoke with Barry and straightened out my own understanding of the privilege levels within Mailman. Here's the hierarchy as I understand it (the first level has the most power and each successive level has less power):
site administrator - has command-line (shell) access to the machine. (The website's system administrator, usually.) Has ultimate power! Can invoke "mailman stop", for instance, to stop mailman services.
Mailman administrator - does not have command line access to the machine, but can use the web interface to change everything within the Mailman installation on that site (that is, can do anything Postorius lets you!). Can create, change, and delete domains, lists, users, and so on.
domain administrator - Any given list belongs to 1 and only 1 domain, which correlates to an actual internet domain name, such as mozilla.org. A domain administrator can create, change/administer, and delete lists. If you set up multiple domains, you can, e.g., have one domain administrator who has power over the lists at the 70 lists at example.com, and another domain administrator for the 40 lists at example.org.
list administrator - can change list settings such as preferred language, digest threshold, footer, etc., and moderate messages, manage users, etc.
list moderator - cannot change the list's settings as a list administrator could, but can allow/reject messages on moderated lists or that trip certain rules, approve subscriptions, ban users, etc.
user - can change their own user preferences
I do not know where all this is laid out in the code, though. And I am totally willing to be told I have gotten the nomenclature wrong!
Sumana Harihareswara http://brainwane.net
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. :)
OK.
How about I make a standalone User Authorisation based server that has a user data store with additional arbitrary user keys in it? It would also allow role information to be assigned to those users via it’s own REST API (which I would have to think about and make up).
Thus my API proxy (I’m calling it CrowdWave) will be a public front end that looks like this:
public HTTP request <==> CrowdWave API proxy <==> Mailman REST API public HTTP request <==> CrowdWave API proxy <==> CrowdWave User Authorisation server
The CrowdWave User Authorisation server will use Falcon and Sqlalchemy with a default sqlite database.
I’ll just do it to meet my need for resolution of question of how to give public access to higher than list level functions. I’m not going to overthink it because I just want a way to give public access to all Mailman REST API functions. Consistent with earlier discussion, the CrowdWave User Authorisation server would not in the short term be part of the Mailman project and would be a third party project.
After this is built it might be an effective thinking point for working out the official mechanism for authorisation.
Barry - if you want me to implement a specific approach now would be a good time to say - I’m happy to do anything as long as I feel up to it from a coding perspective. Right now I’m aiming for super simple.
What do you think?
as
On 26 Jan 2015, at 4:44 am, Barry Warsaw <barry@list.org> wrote:
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. :)
Mailman-Developers mailing list Mailman-Developers@python.org https://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: https://mail.python.org/mailman/options/mailman-developers/andrew.stuart%40s...
Security Policy: http://wiki.list.org/x/QIA9
Andrew Stuart writes:
Right now I’m aiming for super simple.
This worries me. Nothing in security is simple (except for the "Orange Book" and "RMS" models: the former being "it can't be attacked if you don't plug it in" and the latter being "password communism" a la Stallman).
At present, we just don't much care because historically the subscriber database and archives rarely required much if any security, and when such security was needed we simply did a "deny all" except for root on the server, which of course was a single host.
But with the advent of DMARC (and the "4/14 Debacle" at Yahoo! and AOL), I suspect that the price of "known good" address lists is rising in the underworld, and there will be attacks on Mailman security just to get addresses. We're also trying to make it easier to access and mutate enterprise databases through the Mailman APIs. That could make Mailman a vector for attacks on those databases.
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.
I'm afraid that is changing, Mr. General FLUFL Sir. The core is concerned with mail distribution, which historically has been the no-security SMTP protocol. If your core product *can't* be secure, I would expect that you have little need for security, and what security you do need can be implemented simply by hiding everything else in a server on a single host with only root access to anything. Especially with the various expanded roles that are already appearing in Postorius and HyperKitty, is that going to be true going forward?
Of course in current Mailman practice, all this is FUD. But the fear is real, even if the threats are (so far) unrealized. And of course the cost of a flexible and tight security model is high, both in design effort and in complexity of the resulting system.
participants (5)
-
Andrew Stuart -
Barry Warsaw -
Stephen J. Turnbull -
Sumana Harihareswara -
Terri Oda