Ticket #8901 (closed PLIP: wontfix)

Opened 7 years ago

Last modified 5 years ago

Deleting a user should revoke roles

Reported by: erikrose Owned by: erikrose
Priority: major Milestone: Future
Component: General Version:
Keywords: Cc: esteele, plip-advisories@…

Description (last modified by erikrose) (diff)

Proposed by: Erik Rose
Seconded by: Matthew Wilkes

Motivation

Deleting a user doesn't revoke its roles. If you...

  1. Create a user using the Users and Groups configlet
  2. Assign the user some global roles
  3. Delete the user

...the user is still mapped to roles in plone-site/acl_users/portal_role_manager.

As a result, if you ever create another user with the same ID, it inherits all the roles of the former user. Further, in deployments using plugins like PloneLDAP or WebServerAuth which authenticate against a user store outside Plone, a user's privileges cannot be revoked by deleting the user. This has been a security hole for us in practice; at the very least, it is an unpleasant surprise.

Proposal

  1. Remove global role assignments on user deletion.
  2. Prompt the site admin to:
    • Reassign ownership of the user's objects, as on  PLIP 185. Prompt for who to assign them to, like the Types configlet prompts for state mappings when switching workflows. This step also addresses the motivation of the previous PLIP, which was that content with no existing owner "can lead to unpredictable behavior" and that "it is not always possible [to] easily reassign ownership through the Plone UI".
    • Walk the site and revoke the user's local roles.
  3. Provide a button someplace to do step 2 at some later, low-traffic time, since it's likely to be expensive on large sites.

Risks

  1. While revoking local roles, each object granting roles to the user being deleted would be modified (assuming role mappings are stored on the individual objects, which I'm not sure of). This could cause conflict errors.
  2. As mdziergwa says below, redoing the allowedRolesAndUsers index on each local-role-holding object could be a performance hit on large sites.

Both of these are mitigated by the possibilty of deferring the site walk, as described under Proposal. Also note the similarity to what already happens when switching workflows using the Types configlet; this isn't considered too expensive to allow. Granted, deleting a user is probably a more frequent occurrence than switching workflows.

Progress

The ownership reassigning is already done in  iw.memberreplace; perhaps Ingeniweb would lend us some code. memberreplace also offers to replace local role assignments, which should be trivial to adapt to deleting them.

I volunteer to coordinate/do the implementation, as I'm fairly familiar with PAS internals. I've also briefly tangled with the Users & Groups configlet in the past, though I'm sure I'll have questions when we get to that point.

Change History

comment:1 Changed 7 years ago by mdziergwa

  • Priority changed from critical to major

AD1. I dont think removing localroles is a good idea. We implemented such solution once for on portal, and when site is getting bigger it will kill it. You have to remember that you also have to reindex given object for allowedRolesAndUsers index.

AD2. The other solutio is removing content owned by this user. If you want reasing than the question is to whom

comment:2 Changed 7 years ago by glenfant

There's a related issue (side effects of member removal) at https://dev.plone.org/plone/ticket/7948

comment:3 Changed 7 years ago by hannosch

  • Component changed from Users/Groups to Infrastructure

comment:4 Changed 7 years ago by erikrose

  • Type changed from Bug to PLIP
  • Milestone changed from 3.x to 4.0

Changed to a PLIP (perhaps just temporarily) to remind me to get the Framework Team's input on it. Also, I suppose it could be considered a big enough change to require a major release (though that would be a shame from a security perspective).

comment:5 Changed 7 years ago by alecm

  • Type changed from PLIP to Bug

Please turn this into a proper PLIP before calling it such.

comment:6 Changed 7 years ago by erikrose

  • Type changed from Bug to PLIP
  • Description modified (diff)
  • Summary changed from Deleting a user doesn't delete his roles to Deleting a user should revoke roles

How's that, alecm? (Sorry, I'd meant to get to that earlier.)

comment:7 Changed 7 years ago by erikrose

  • Description modified (diff)

Volunteered to implement. Solicited a seconder.

comment:8 Changed 7 years ago by MatthewWilkes

  • Description modified (diff)

comment:9 Changed 7 years ago by erikrose

  • Description modified (diff)

Noted this is a superset of PLIP 185. Noted implementation work already done in iw.memberreplace.

comment:10 Changed 7 years ago by erikrose

  • Description modified (diff)

Noted this also solves the problem targeted by PLIP 185.

comment:11 Changed 7 years ago by pupq

I'm not sure I understand the technical implications of this, but, in classes, integrators ask all the time: "if we delete a user and create a user with the same name, will they get the same localroles as the original user." People do worry about this.

So, assuming the implementation doesn't break things, from integrator-land, this would be a big +1.

comment:12 Changed 7 years ago by esteele

  • Cc esteele added

comment:13 Changed 7 years ago by MatthewWilkes

I think we do need to consider the performance issues of this. I can, however, think of no reason that this should not be fixed.m The deleteLocalRoles method of portal_memberdata looks like it should already work, if not, building on this work is a good idea.

Allowing developers some way of disabling this would be a good idea, preferably with some sort of subscriber-based customisation, but that's all just nicities.

comment:14 Changed 7 years ago by hannosch

Just to give an indication of the performance problem: Trying to change the ownership of or remove the locales roles while deleting a user caused user deletion in our case to take about 15 minutes. Now the end user saw some kind of timeout and tried the operation again, which caused a conflict error. The actual change completed after keeping a ZEO client busy for 45 minutes. If not done carefully this can be extremely slow!

I still think the only proper solution to this is adopting the Unix/Windows approach of using either increasing integers or some form of uuid's as the internal markers for users and ensure these cannot be taken again by any normal means. These internal identifiers would than be mapped to names, login ids, nick names or mail addresses of which some might be used to establish a connection to an external system.

In doing so, one would avoid the need to remove any of these entries, since even if an account would be deleted, the same internal id could not be taken again. I think such an approach is also needed to fully support changing of login ids (the typical case when using surnames: I got married, my last name changed...) or allowing multiple identifiers (for example nickname + mail address) as login credentials.

comment:15 Changed 7 years ago by hannosch

My comment doesn't mean, we shouldn't do something about the current situation and my remarks are probably outside the scope of this PLIP.

I cannot resist to make another point ;) I worked in the healthcare industry for most of my live, where usually persons are identified by the combination of their full name, birth date and gender. In web sites we tend to have other bases like mail address or login id. What is common to all of these, is that they do not uniquely identify a person over time and all of them can change. In the common case most of these are somewhat stable and only surnames and mail addresses tend to change more often. But in the more uncommon cases any of the other ones change as well. That does indeed include gender and birth dates, even it those tend to be quite rare.

There is indeed a good reason why almost all other systems use numbers to identify persons, as seen in social security numbers, tax numbers, drivers license numbers, passport numbers, ...

comment:16 Changed 7 years ago by erikrose

I still think the only proper solution to this is adopting the Unix/Windows approach of using either increasing integers or some form of uuid's as the internal markers for users and ensure these cannot be taken again by any normal means.

I like it! PAS already has separate ideas of loginname and userid, though I hear we conflate them sometimes in Plone's code. And I, also, am a longtime fan of surrogate keys. I've learned through years of writing business software that the only way to keep a client from wanting to change a key is to strip it of all meaning.

comment:17 Changed 7 years ago by erikrose

Clearing Owner field of 4.0 PLIPs so we can use it to mean "implementor". (Many of these owners were automatically assigned from choosing a Component that had a default owner.)

comment:18 Changed 7 years ago by smcmahon

  • Cc plip-advisories@… added

comment:19 Changed 7 years ago by rossp

My FWT vote is +1 as long as it doesn't include changing local roles. It seems pretty clear that needs to be a separarte PLIP and requires lots of discussion and possibly changes to the underlying local role infrastructure.

comment:20 Changed 7 years ago by MatthewWilkes

So, given Hanno's numbers on performance loss, I think implementing this for the default case would be problematic. As there's already an add-on product that does this, I think documentation pointing at it will probably be sufficient, but we should prioritise "getting it right" for a future release. That will likely be Hard.

Sorry Erik

FWT Vote: -1

comment:21 Changed 7 years ago by davisagli

My FWT vote: -1 on the PLIP as worded here, mainly due to the performance concerns. However this is a really important problem and I'd like to encourage further research into other ways to solve it.

comment:22 Changed 7 years ago by raphael

FWT vote: 0

I'm really undecided here. I'd say the current behavior is a bug but given the performance it when changing it naively that would be unacceptable - at least if always triggered.

And what if we make the local role removal optional on user deletion (similar to what CMF offers for content owned by a user on deletion?) and warn that choosing this may take a lot of time?

comment:23 Changed 7 years ago by calvinhp

FWT Vote: -1 I think the problem is very important to address, but the proposed solution has too many performance issues to introduce it now. I'd be +1 if the performance issue can be addressed.

comment:24 Changed 7 years ago by erikrose

Abstaining since this is my PLIP.

comment:25 Changed 7 years ago by erikrose

  • Description modified (diff)

Revised to defer expensive operations till the middle of the night.

comment:26 Changed 7 years ago by esteele

Approved by FWT vote.

comment:27 Changed 7 years ago by esteele

  • Owner set to erikrose

comment:28 Changed 7 years ago by erikrose

  • Status changed from new to assigned

comment:29 Changed 6 years ago by esteele

  • Milestone 4.0 deleted

comment:30 Changed 6 years ago by limi

  • Milestone set to Future

comment:31 Changed 5 years ago by rossp

  • Status changed from assigned to closed
  • Resolution set to wontfix

PLEASE READ THIS AND RE-OPEN VALID PLIPS!

As we launch the new PLIP process we'd like to see which PLIPs:

  • are still appropriate/needed
  • still have owners/proposers/champions
  • still have available implementers

If this PLIP should still be considered for future releases of Plone please do re-open this ticket and assign an appropriate milestone. If it should be considered for the next release of Plone, use the 4.2 milestone. Also be sure to update the PLIP description, requester, owner, etc. and include a comment detailing recent progress and new plans. We will use all these details in the new continuous PLIP process.

comment:32 Changed 4 years ago by davisagli

  • Component changed from Infrastructure to General
Note: See TracTickets for help on using tickets.