ACL Permission Issue | Community
Skip to main content
T
test1234567
Level 6
November 12, 2025
Question

ACL Permission Issue

  • November 12, 2025
  • 3 replies
  • 298 views

I have encountered an issue while updating the page properties. There is a deny rule for everyone group as shown in the below screenshot.

 

Users belonging to a specific group are unable to update page properties, even though they have Read, Modify, Create, and Delete permissions for the required path. The necessary permissions for /content have been granted, but these users continue to receive an error.

To resolve the issue, I added the jcr:modifyProperties privilege, after which the error was resolved. However, I noticed that jcr:modifyProperties was not listed among the original privileges, and I verified the rep:policy node as well.

Interestingly, when I remove the rep:write privilege and add only jcr:modifyProperties, I can see the entry, which suggests that jcr:modifyProperties is an aggregate privilege of rep:write. This raises the question: why did it not work when rep:write was granted, and why was the explicit addition of jcr:modifyProperties required?

Furthermore, I do not see an entry for jcr:modifyProperties among the assigned privileges by default.

 

 

 

 

3 replies

Karishma_begumSh
Karishma_begumSh
Level 4
November 12, 2025

Hi @test1234567 

The issue occurred because of a deny rule applied to the everyone group under /content, which restricted certain property modifications. Although the specific user group had Read, Modify, Create, and Delete permissions with rep:write, they were still unable to update page properties.

To fix this, I explicitly added the jcr:modifyProperties privilege, after which the users were able to update the page properties successfully.

The reason this was necessary is that rep:write is an aggregate privilege, which internally includes

jcr:modifyProperties
jcr:addChildNodes
jcr:removeNode
jcr:removeChildNodes

 

However, when a deny rule is in place (especially for everyone), it can block specific sub-privileges inside the aggregate — even if rep:write is granted elsewhere. In this case, the deny rule effectively prevented property modifications.

By explicitly granting jcr:modifyProperties, I created a direct allow privilege, which overrides the deny restriction for property updates.

Also, jcr:modifyProperties does not appear by default in the permission list because it is part of the aggregate rep:write privilege. It only appears when explicitly added.

 

Hope this helpful:)

 

Regards,

Karishma.

 

T
test1234567Author
Level 6
November 12, 2025

Thank you for your inputs. I understand that jcr:modifyProperties is part of the aggregate rep:write permission, and therefore it won't be visible in the permission list. However, I would like to know how the permissions are being resolved for this issue. Can you tell me where these permissions are stored—are they kept somewhere in the registry and not visible on the rep:policy node?
I just want to confirm whether the permission (jcr:modifyProperties) I have added is being stored somewhere and handled by the services, even though it is not visible in the permissions console.

ManviSharma
Adobe Employee
ManviSharmaAdobe Employee
Adobe Employee
November 12, 2025

Hello @test1234567 ,

 

I reviewed the behaviour:

Cause for your issue: There is a deny rule on /content with the privilege rep:write, combined with a glob restriction:

rep:glob="/*/cq:target-ambits"

This means:
“Deny rep:write on any node under /content that has a child named cq:target-ambits.”

Even though users have rep:write (which includes the ability to modify properties), this deny rule takes priority for any path that matches the glob pattern.
When a deny rule includes a restriction, the deny applies only when the target path matches the restriction - and in your scenario, the page property update internally triggers operations on nodes that match this glob.


-> Why rep:write did not work

rep:write is an aggregate privilege that includes:

  • jcr:modifyProperties

  • jcr:addChildNodes

  • jcr:removeNode

  • jcr:removeChildNodes

Because the deny rule applies to rep:write, AEM evaluates each underlying privilege individually.
So the deny was effectively blocking:

  • jcr:modifyProperties (needed for editing page properties)

This is why users received an error even though they had full Write permissions.

Why explicitly adding jcr:modifyProperties fixed it

When you add an explicit allow jcr:modifyProperties entry for the user group:

  • It becomes more specific than the deny rule on everyone.

  • A specific allow for the principal overrides a deny that applies only through a glob restriction.

  • This restores the ability to update properties, even though rep:write was still partially blocked by the deny.

This is expected behavior based on how AEM ACL evaluation works:

  1. Specific ACE for the user or their group

  2. Then restricted ACEs (with glob, rep:ntNames, etc.)

  3. Then everyone

  4. Deny only wins if all other conditions are equal

Why jcr:modifyProperties does not appear by default

Because it is normally inherited from the aggregate privilege rep:write.
You only see it listed when you add it explicitly.


In conclusion:

  • The deny rule with glob restriction was blocking the “modify properties” part of rep:write.

  • Adding an explicit allow for jcr:modifyProperties created a more specific ACE that overrode the deny.

  • This is expected with Oak’s privilege aggregation and ACE evaluation rules.

Please let me know if you would like a recommended path-forward for restructuring the ACLs so that these conflicts don’t occur again.

Regards,
Manvi

T
test1234567Author
Level 6
November 12, 2025

Thank you for your detailed inputs. Upon further investigation, I found that jcr:modifyProperties did not resolve the issue. The root cause appears to be related to the order of ACL entries. If "allow" is the last entry in the list, everything works as expected. However, if "deny" is the last entry, I receive an error when updating the page properties.

I'm not sure what additional permissions must be granted for the same path so that it works regardless of the order of the ACL entries. Adding permissions at a deeper level(i.e. /content/project/test) is one option, but I would prefer to add the necessary permissions directly to the same path, i.e. /content.

 

ManviSharma
Adobe Employee
ManviSharmaAdobe Employee
Adobe Employee
November 12, 2025

Hello @test1234567 ,

 

Right. Oak/AEM evaluates access control entries in the order they appear and applies the first matching decision rules in context; combined with deny semantics, a deny that matches the request can block the operation even if an allow also exists for the same path/principal.

You asked for ways to make updates succeed regardless of ACE order while keeping the ACEs on the same path (/content). Here are safe, recommended approaches (ordered by preference):

1. Narrow the deny instead of widening allows (recommended)

  • Replace the broad deny for everyone with a more specific deny that targets only the nodes that must be blocked. Use restrictions such as rep:glob or rep:ntNames to limit scope.

  • Example: if you only want to deny write for nodes with a child cq:target-ambits, keep the deny but use rep:glob="/*/cq:target-ambits" (as you already have) - ensure it does not match the nodes your property update touches. Narrowing prevents accidental blocking of generic property updates.

VishalKa5
VishalKa5
Level 5
November 13, 2025

Hi @test1234567 ,

Please check this way if possible:-

rep:write is an aggregate privilege that includes jcr:modifyProperties, but if there’s a deny rule higher in the hierarchy (like for the everyone group), it overrides that part of the privilege.

So even though your group had rep:write, the deny on jcr:modifyProperties inherited from the parent path prevented property updates. When you explicitly added jcr:modifyProperties allow permission at that node, it overrode the deny and resolved the issue.

In short: the deny rule on a higher level blocked property modification despite rep:write; explicitly granting jcr:modifyProperties locally allowed it.

 

Terms & ConditionsAccessibility statement

Loading footer...