Soliciting feedback on idea for rounding out the permissions model.
I had an idea about rounding out the Mailman permissions model, interested in hearing thoughts on it. Obviously there has been considerable discussion on this topic before.
Mailman already carries much of the information needed for determining user permissions to Mailman resources. Only two things are missing: 1: the ability to define a user as being a “serverowner” 2: the ability to define a user as being a “domainowner”
(You’ll need to look at this email in plain text to see the table properly).
The Mailman permissions model currently looks like this:
resource_type roles resource_id user_identifier where to find permission
user userowner n/a UUID (defined in user record)
list listowner list_id subscriber (defined in list member record)
list listmember list_id subscriber (defined in list member record)
list listmoderator list_id subscriber (defined in list member record)
list listnonmember list_id subscriber (defined in list member record)
I am suggesting adding two further permissions to the existing permissions model, which would look like this:
resource_type roles resource_id user_id where to find permission
server serverowner n/a UUID (not currently defined in Mailman) domain domainowner mail_host UUID (not currently defined in Mailman)
To implement, it would need to be possible to define as user as being a ‘serverowner’, and also to be able to define a user as being a ‘domainowner’ for any given domain.
If it were possible to do so within the Mailman core then there would be a completely usable permissions model entirely within Mailman, and no need to store any additional permissions data outside Mailman. The permissions model would allow definition of user access to any Mailman resource including domains and servers.
The interpretation of the permissions would still be up to the application that consumes the REST API, as is currently the case.
Thoughts?
as
This looks like a reasonable analysis.
On Feb 16, 2015, at 11:39 AM, Andrew Stuart wrote:
To implement, it would need to be possible to define as user as being a ‘serverowner’, and also to be able to define a user as being a ‘domainowner’ for any given domain.
As you've noticed, we have IMember objects which encapsulate the list-centric roles for users. It's important to note though that this isn't quite complete because it's possible for validated, non-user linked addresses to also be subscribed to mailing lists, and then we have no trail back to a UUID. I think in normal operations though, this should be rare to nonexistent.
We have a natural place to hang user information on for domains, since we have an IDomain interface (and a domain model/table). In this case, I would stipulate that only users can be associated with domains. We'd probably need to add a table to represent this relationship.
I don't know where to hang the siteowner information. Maybe adding a column to the user table? It probably just needs to be a flag.
The alternative is to use some special list_id values in the member table to denote a domain and the site, and then restrict the role to owner in both cases. I'm not sure I like this though. It seems implicit rather than explicit.
Are there any other permissions you can think of?
Cheers, -Barry
Are there any other permissions you can think of?
I figured that an archive, which isn’t really a Mailman resource anyway(?), has the same permissions as the list that it gets its emails from.
Are there any other Mailman resources beyond user, list, domain, server? There is member, but that is really more of a relationship between a user and a list - not a standalone resource that requires permissions - is that right?
as
On 17 Feb 2015, at 1:37 am, Barry Warsaw <barry@list.org> wrote:
This looks like a reasonable analysis.
On Feb 16, 2015, at 11:39 AM, Andrew Stuart wrote:
To implement, it would need to be possible to define as user as being a ‘serverowner’, and also to be able to define a user as being a ‘domainowner’ for any given domain.
As you've noticed, we have IMember objects which encapsulate the list-centric roles for users. It's important to note though that this isn't quite complete because it's possible for validated, non-user linked addresses to also be subscribed to mailing lists, and then we have no trail back to a UUID. I think in normal operations though, this should be rare to nonexistent.
We have a natural place to hang user information on for domains, since we have an IDomain interface (and a domain model/table). In this case, I would stipulate that only users can be associated with domains. We'd probably need to add a table to represent this relationship.
I don't know where to hang the siteowner information. Maybe adding a column to the user table? It probably just needs to be a flag.
The alternative is to use some special list_id values in the member table to denote a domain and the site, and then restrict the role to owner in both cases. I'm not sure I like this though. It seems implicit rather than explicit.
Are there any other permissions you can think of?
Cheers, -Barry
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 Feb 17, 2015, at 12:37 PM, Andrew Stuart wrote:
I figured that an archive, which isn’t really a Mailman resource anyway(?), has the same permissions as the list that it gets its emails from.
I think so. The owner of the mailing list has authoritative control over which archivers are enabled for their list, and their public/private exposure. In MM2, when list owners deleted their lists, they could decide whether to keep or delete the associated archives, but I don't think that will be possible with MM3 (at least, not via the core).
Are there any other Mailman resources beyond user, list, domain, server? There is member, but that is really more of a relationship between a user and a list - not a standalone resource that requires permissions - is that right?
IMO, yes.
Cheers, -Barry
Andrew Stuart writes:
Are there any other permissions you can think of?
I figured that an archive, which isn’t really a Mailman resource anyway(?),
Not in the sense that core can enforce any restrictions on archives. Back in the bad old days, I had a ~/public_html and AltaVista crawled right up to ~ and back down into my personal folders, to the great shock of a coauthor who thought he'd only only shared his draft with me. Me, too. While httpds got smarter than that after a while, it would be quite easy for a malicious person or whistleblower to subscribe and publish in many cases.
N.B. One of my Systers GSoCs wrote a "Mailman control panel" that gave access to all Mailman features (posting, reading, archives, admin). The current separation of user admin (both by admins and users themselves) of the Big 3 components has never really sat well with me.
has the same permissions as the list that it gets its emails from.
Are there any other Mailman resources beyond user, list, domain, server? There is member, but that is really more of a relationship between a user and a list - not a standalone resource that requires permissions - is that right?
In Mailman 2, and I believe in Postorius, there's a per-list setting for whether one is visible as a member of a given list. So yes, membership is a resource.
As you've noticed, we have IMember objects which encapsulate the list-centric roles for users. It's important to note though that this isn't quite complete because it's possible for validated, non-user linked addresses to also be subscribed to mailing lists,
@Barry: Why? Why not just make a dummy user for each such non-user?
On Feb 17, 2015, at 01:36 PM, Stephen J. Turnbull wrote:
As you've noticed, we have IMember objects which encapsulate the list-centric roles for users. It's important to note though that this isn't quite complete because it's possible for validated, non-user linked addresses to also be subscribed to mailing lists,
@Barry: Why? Why not just make a dummy user for each such non-user?
In practice, it does. It's just that the model allows for bare addresses to be used when creating member records.
Cheers, -Barry
I’d be interested to hear what the Postorius/Hyperkitty folks think on the concept of more tangibly defining Mailman resource/user permissions.
Presumably Postorius and Hyperkitty somehow grant access to resources and store the permissions information externally?
Anyone got any thoughts?
as
On 17 Feb 2015, at 1:37 am, Barry Warsaw <barry@list.org> wrote:
This looks like a reasonable analysis.
On Feb 16, 2015, at 11:39 AM, Andrew Stuart wrote:
To implement, it would need to be possible to define as user as being a ‘serverowner’, and also to be able to define a user as being a ‘domainowner’ for any given domain.
As you've noticed, we have IMember objects which encapsulate the list-centric roles for users. It's important to note though that this isn't quite complete because it's possible for validated, non-user linked addresses to also be subscribed to mailing lists, and then we have no trail back to a UUID. I think in normal operations though, this should be rare to nonexistent.
We have a natural place to hang user information on for domains, since we have an IDomain interface (and a domain model/table). In this case, I would stipulate that only users can be associated with domains. We'd probably need to add a table to represent this relationship.
I don't know where to hang the siteowner information. Maybe adding a column to the user table? It probably just needs to be a flag.
The alternative is to use some special list_id values in the member table to denote a domain and the site, and then restrict the role to owner in both cases. I'm not sure I like this though. It seems implicit rather than explicit.
Are there any other permissions you can think of?
Cheers, -Barry
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
participants (3)
-
Andrew Stuart -
Barry Warsaw -
Stephen J. Turnbull