How are nested page permissions handled during bulk node movements in Sulu?

Question

Permission Inheritance in Page Tree Reorganization
Sulu CMS manages content through a hierarchical page-tree structure, where permissions are often inherited or defined at specific node levels. When moving a page node—along with its entire subtree—to a different parent in the administration interface, the system must reconcile the existing permissions of the moved nodes with the permissions of the new parent node.
There is uncertainty regarding whether the system preserves the explicit permissions assigned to the moved subtree or if it forces a recalculation based on the new parent's permission set to prevent security leaks.

Does the movement of a page node trigger a recursive update of all child permissions?
  Which mechanism ensures that inherited permissions are correctly mapped without creating orphaned access rules?

Tasadduq Burney · Answer

Permission Logic During Node Reorganization
In Sulu CMS, moving a page node (and its subtree) to a new parent does not trigger a recursive overwrite of explicit permissions. Instead, the system preserves any permissions specifically assigned to the moved nodes while recalculating the effective access based on the new parent's hierarchy.

Confirmed Behavior

Explicit Permissions: Permissions directly assigned to a page entity are persisted. They are linked to the entity ID, not the page path, meaning they survive the movement.
  Inherited Permissions: Because Sulu uses a hierarchical model, child nodes inherit the access constraints of their parent. When a node is moved, it immediately inherits the permissions of the new parent.
  Path Recalculation: The system updates the parent-child relationship in the database, which triggers a recalculation of the page paths for the entire moved subtree.

Likely Implementation and Risks
The reconciliation typically happens via the Sulu Page repository and the underlying RBAC (Role-Based Access Control) mapping. While the movement itself is a database update to the parent_id, the security impact is immediate due to how the permission voters evaluate the tree.

Potential Risks:

Access Revocation: If a subtree is moved from a "Public" parent to a "Restricted" parent, users who relied on inheritance from the old parent will lose access, even if the child nodes themselves have no explicit restrictions.
  Performance: In very large trees, bulk movements can cause temporary latency due to recursive path updates and the subsequent invalidation of the system cache.
  Custom Voters: If you have implemented custom permission voters that rely on absolute URL paths rather than entity IDs, these will break upon movement.

Verification Steps
To verify the permission state after a bulk move, perform the following:

Move a child page to a parent with known restrictive permissions via the Sulu admin panel.
  Log in with a user account that has access to the child but not the new parent to check if explicit permissions are still honored.
  Log in with a user who has access to the new parent but not the child to verify inheritance is functioning.
  Clear the system cache to ensure the admin UI reflects the current hierarchy accurately.

Diagnostic Detail Needed: Are you using standard Sulu RBAC, or have you implemented custom Symfony Voters for page-level access control?

How are nested page permissions handled during bulk node movements in Sulu?

Permission Inheritance in Page Tree Reorganization

1 answer

0 question comments

Permission Logic During Node Reorganization

Confirmed Behavior

Likely Implementation and Risks

Verification Steps

Your perspective belongs here.