[MAGNOLIA-3815] Editing users deletes roles if permissions to read roles are missing Created: 30/Aug/11  Updated: 04/Aug/15  Resolved: 04/Aug/15

Status: Closed
Project: Magnolia
Component/s: admininterface, security
Affects Version/s: 4.4.3
Fix Version/s: None

Type: Bug Priority: Neutral
Reporter: Richard Unger Assignee: Philipp Bärfuss
Resolution: Outdated Votes: 0
Labels: security, usermanager
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Magnolia EE 4.4.3, Plattform/Hardware doesn't matter


Attachments: Text File MAGNOLIA-3815.stacktrace.txt    
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

When a user is edited, if the user who is doing the editing does not have at least read-access to the roles assigned to the user being edited, these roles will be deleted when the user is saved.

Not only that, but they will be "partially" deleted, resulting in an incorrectly configured user node which can still work, but causes exceptions in the login-processing. (See stack trace in comments).
This is because when the roles are deleted, the property for the deleted role is not removed, but only its content is deleted, leaving an empty property attached to the "roles" node in the user node.
This results in an NPE when the security attempts to instantiate the UUID.

Suggested fix:
Don't delete roles the current user cannot read when the user dialog is saved!

Undesireable, but better than the status-quo:
Delete the roles properly.

Background info:

We are implmenting a kind of delegated security model for our customer:

  • Roles and Groups are configured exclusively by us (we have superuser rights)
  • Admins on the customer side have the right to create and manage users
  • They can assign groups to the users
  • They can read (but not write!) the groups
  • They cannot read or write the roles

In this way, we set up the security policies via the roles we create for the customer, and assign the roles to groups which the customer can use to configure which user can do what.
The customer has hundereds of users, which is why we do it this way.



 Comments   
Comment by Richard Unger [ 30/Aug/11 ]

Stack-Trace of the exception caused by this problem in attachment.

Comment by Michael Mühlebach [ 04/Aug/15 ]

We're closing this issue as outdated as it was reported for 4.4.x or earlier versions which are no longer supported. Don't hesitate to reopen or create a new ticket in case this is still relevant and you'll experience it on 4.5.x or later versions.

Generated at Mon Feb 12 03:49:56 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.