Skip to content

ACL ownership insufficient to CHANGE_AUDITING #17848

@n12c

Description

@n12c

If we create a new ACL, set ourselves as the owner, create the first ACE assigning some permission to some SID, and try to change the auditing flags on the ACE, the request fails in AclAuthorizationStrategyImpl#securityCheck:

// Check if authorized by virtue of ACL ownership
Sid currentUser = createCurrentUser(authentication);
if (currentUser.equals(acl.getOwner())
&& ((changeType == CHANGE_GENERAL) || (changeType == CHANGE_OWNERSHIP))) {
return;
}

Apparently ownership is enough to give away ownership to another SID or to add, update, and delete ACEs, but it is not enough to update the auditing flags on existing ACEs.

To work around this we must make our first ACE one which gives the administration permission to the owner; securityCheck will then accept our attempts to update the auditing flags on subsequent ACEs.

Is this intentional? If so, why? If not, can securityCheck be changed so that ACL ownership is good enough for auditing changes too?

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions