Users with Edit permissions can Override the Delete capabilities #5307

New Issue

OVERLORD · 2026-02-05T09:56:38+03:00

OVERLORD commented

2026-02-05 09:56:38 +03:00

Originally created by @joshhcd on GitHub (Jun 4, 2025).

Describe the Bug

I believe this is currently "as expected", however its an issue a user brought up to me last week.

I currently have all user assigned roles to not include delete capabilities, so that nothing is removed without an administrators consent.

However, uses with Edit permission can simply edit the permissions of the entity and uncheck Inherit defaults, allowing them to grant permission to delete the book/page/etc.

Steps to Reproduce

Remove delete permissions from a role for all entities, but leave edit permissions

Go to any entity and "edit" permissions

Simply uncheck Inherit defaults, and check the delete permission. You can now delete the entity.

Expected Behaviour

Ideally, specifically for the delete function, this should be disabled when it is unchecked on a role level. Users should not be able to access the delete button by manually assigning permissions.

At the very least, this should be a separate toggle on a role level.

Screenshots or Additional Context

No response

Browser Details

No response

Exact BookStack Version

v25.02.3

Originally created by @joshhcd on GitHub (Jun 4, 2025). ### Describe the Bug I believe this is currently "as expected", however its an issue a user brought up to me last week. I currently have all user assigned roles to not include delete capabilities, so that nothing is removed without an administrators consent. However, uses with Edit permission can simply edit the permissions of the entity and uncheck Inherit defaults, allowing them to grant permission to delete the book/page/etc. ### Steps to Reproduce 1. Remove delete permissions from a role for all entities, but leave edit permissions ![Image](https://github.com/user-attachments/assets/adb08efa-18c2-4c53-9d9a-5ca00ea62c24) 2. Go to any entity and "edit" permissions ![Image](https://github.com/user-attachments/assets/411a74d9-3a52-4e06-97a2-ba5f2970f199) ![Image](https://github.com/user-attachments/assets/58f39eb5-b801-41c2-926b-2ecefd015b4a) 3. Simply uncheck Inherit defaults, and check the delete permission. You can now delete the entity. ### Expected Behaviour Ideally, specifically for the delete function, this should be disabled when it is unchecked on a role level. Users should not be able to access the delete button by manually assigning permissions. At the very least, this should be a separate toggle on a role level. ### Screenshots or Additional Context _No response_ ### Browser Details _No response_ ### Exact BookStack Version v25.02.3

OVERLORD added the 🐛 Bug label 2026-02-05 09:56:38 +03:00

OVERLORD commented

2026-02-05 09:56:40 +03:00

@ssddanbrown commented on GitHub (Jun 5, 2025):

Thanks for the input @joshhcd, but to be honest I wouldn't be keen on having different behaviour for delete compared to others, or otherwise adding complexity (options, extra control) to work around this somewhat specific scenario which essentially comes down to expectations/understanding.

I would expect that specifically assigning delete permission to provide the ability to delete.
If you expected that to intersect with the role level permission, then really I'd have thought you would expect the same for the other permissions too, and then the result is quite a different permission system behaviour.

@ssddanbrown commented on GitHub (Jun 5, 2025): Thanks for the input @joshhcd, but to be honest I wouldn't be keen on having different behaviour for delete compared to others, or otherwise adding complexity (options, extra control) to work around this somewhat specific scenario which essentially comes down to expectations/understanding. I would expect that specifically assigning delete permission to provide the ability to delete. If you expected that to intersect with the role level permission, then really I'd have thought you would expect the same for the other permissions too, and then the result is quite a different permission system behaviour.

OVERLORD commented

2026-02-05 09:56:42 +03:00

@joshhcd commented on GitHub (Jun 9, 2025):

Thanks for the reply @ssddanbrown ,

I agree that it boils down to understanding what the limitations are, if you allow role permissions to be overridden.

The current setup however makes it impossible to restrict object deletion based on a role level, while still allowing users to modify the books pages itself. This issue is only a security concern from a delete perspective, not from a view/update/create perspective.

I would expect that specifically assigning delete permission to provide the ability to delete. If you expected that to intersect with the role level permission, then really I'd have thought you would expect the same for the other permissions too, and then the result is quite a different permission system behaviour.

The reason being is that It is possible to restrict editing based on the role, and since the user does not have editing privileges, they do not have access to the permissions page to give themselves access. This should be a fairly simple and unintrusive to change the page permission level, to simply not show the user the delete checkbox, if their role does not allow them to delete.

While this change does not inherently prohibit the delete checkbox from being activated by a higher level user for that role, it would prevent privilege-escalation risk.

@joshhcd commented on GitHub (Jun 9, 2025): Thanks for the reply @ssddanbrown , I agree that it boils down to understanding what the limitations are, if you allow role permissions to be overridden. The current setup however makes it impossible to restrict object deletion based on a role level, while still allowing users to modify the books pages itself. This issue is only a security concern from a delete perspective, not from a view/update/create perspective. > I would expect that specifically assigning delete permission to provide the ability to delete. If you expected that to intersect with the role level permission, then really I'd have thought you would expect the same for the other permissions too, and then the result is quite a different permission system behaviour. The reason being is that It *is* possible to restrict editing based on the role, and since the user does not have editing privileges, they do not have access to the permissions page to give themselves access. This should be a fairly simple and unintrusive to change the page permission level, to simply not show the user the delete checkbox, if their role does not allow them to delete. While this change does not inherently prohibit the delete checkbox from being activated by a higher level user for that role, it would prevent privilege-escalation risk.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/BookStack#5307