jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jens Lauterbach (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OAK-8422) Deleted Users Not Removed From Group
Date Fri, 21 Jun 2019 07:03:00 GMT

    [ https://issues.apache.org/jira/browse/OAK-8422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16869250#comment-16869250

Jens Lauterbach commented on OAK-8422:

{quote}... to limit user management permission to those subjects that have will read/usermgt
access on all users/groups
Not 100% sure I understand. Do you mean with "subjects" people that have permission to do
user management? Like deleting users? We potentially have 10s of thousands of users, but only
a small staff of people that is allowed to do user management.
{quote}but in general {{User.disable}} should be the way to go for a productive environment
That was what we thought about as well. But due to GDPR we also have to consider deleting
users, if they so request.


> 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

View raw message