[
https://issues.apache.org/jira/browse/OAK-8422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16869273#comment-16869273
]
angela commented on OAK-8422:
-----------------------------
[~jenslauterbach], yes... that's what i meant. i was having a java-{{Subject}}
in mind. sorry for the confusion. regarding GDPR: i would check if you really
have to remove the account vs. removing all identifiable information from the
account (essentially leaving it as an empty stub). if you go with removal you
might consider other options to prevent the same userId to be re-used again....
just one random idea that comes to my mind (haven't tested it): move/rename the
user nodes to a different location with a different primary type that is
referenceable and get rid of all user-node specific properties... that would
essentially remove the user while preserving the 'jcr:uuid'. since uniqueness
of jcr:uuid properties is enforce across the repository, subsequent attempts to
create a user with the same ID would fail. a custom authorizable action could
take care of that upon removal.... but i didn't try it out.
> Deleted Users Not Removed From Group
> ------------------------------------
>
> Key: OAK-8422
> URL: https://issues.apache.org/jira/browse/OAK-8422
> Project: Jackrabbit Oak
> Issue Type: Bug
> Environment: Operating system: macOS 10.14.5
> Java:
> {code:java}
> java version "1.8.0_191"
> Java(TM) SE Runtime Environment (build 1.8.0_191-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.191-b12, mixed mode)
> {code}
> Reporter: Jens Lauterbach
> Priority: Major
>
> h1. Overview
> When a user is created, added to a group, deleted and then re-created with
> the same userId (authorizableId) the user is assigned to the group he/she was
> assigned to before the user was deleted. This behaviour is unexpected and is
> potentially a security problem. When a user is created again and gets back
> his/her privileges (through the groups he/she was assigned to before the user
> was deleted), then this could be treated as privilege escalation.
> If an attacker has influence on the userID, for example he/she can choose it
> freely during account creation, then it would be possible to assume the
> identity and privileges of a previously deleted user with higher privileges.
> h1. Steps to Reproduce
> # Create group named "test".
> # Create user.
> # Add user to group.
> # Delete user.
> # Create user with same "userID" as in step 2.
> Expected result:
> * User is not member of group "test".
> Actual result:
> * User is member of group "test".
> h1. Additional Information
> I have created a unit test to demonstrate this problem. The unit test is in
> my fork of the repository and has detailed comments to explain what is going
> on:
> [https://github.com/jenslauterbach/jackrabbit-oak/blob/OAK-8422/oak-core/src/test/java/org/apache/jackrabbit/oak/security/user/UserManagerImplTest.java#L453]
> You can run the test as follows:
> {code:java}
> git clone -b OAK-8422 https://github.com/jenslauterbach/jackrabbit-oak.git
> cd jackrabbit-oak
> mvn test -DfailIfNoTests=false
> -Dtest=org.apache.jackrabbit.oak.security.user.UserManagerImplTest#testDanglingUserGroupMemberships{code}
> This should run the unit test I have written and fail.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
