mirror of
https://github.com/BookStackApp/BookStack.git
synced 2026-02-06 19:06:02 +03:00
Separate permissions options for Allow and Deny #3340
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @alanmcseveney on GitHub (Nov 11, 2022).
Describe the feature you'd like
I would like to be able to deny actions upon Shelf, Book or Page using a permissions option that explicitly denies an action, thereby extending the permissions options to:
Allow: view
Allow: update
Allow: delete
Deny: view
Deny: update
Deny: delete
Explicit Deny permissions should supersede Allow permissions, potentially following the conventions established by Windows ACL's.
Describe the benefits this would bring to existing BookStack users
Not having the ability to explicitly deny access to content can require entire structural changes to existing security groups within an organization. For e.g., here is an Active Directory nest group structure that ends with a group mapped to a Bookstack Role:
user1 is member of "department.region" security group;
"department.region" is a nested member of "department" security group;
"department" is a nested member of "creativedepartments" security group;
"creativedepartments" is a nested member of "bookstack-role-creativedepartments" security group;
"Creative Departments" role in Bookstack has External Authentication ID "bookstack-role-creativedepartments".
user2 is also a member of "department.region", but user2 is a temporary staff member.
user2 should not have access to "Health Insurance & Benefits" Book on the "Human Resources" Shelf.
Explicitly applying a "Deny: view,update,delete" to Bookstack Role "Temporary Staff" for the given book would achieve the desired outcome.
Can the goal of this request already be achieved via other means?
Without the ability to say "Deny: view,update,delete" for "role-temporary-staff", then we have to go all the way to the top of the chain in the directory, and create a new structure like:
department.region.temps > department.temps > creativedepartments.temps > bookstack-role-creativedepartments-temps
department.region.perms > department.perms > creativedepartments.perms > bookstack-role-creativedepartments-perms
This would force us to split the entire permissions structure into a much more complex structure, where the number of required groups increases exponentially.
Have you searched for an existing open/closed issue?
How long have you been using BookStack?
0 to 6 months
Additional context
No response
@ssddanbrown commented on GitHub (Jan 31, 2023):
Thanks for the request @alanmcseveney.
To be honest, I really don't want to complicate the permission system much further for the types of permission levels we already have, since the permission model is already complex enough to maintain.
That said, a significant part of what you desire may be possible.
Lack of permission check can already act as a denial.
Since v22.10 the behaviour of this was somewhat unreliable in complex scenarios but a major part of v23.01 was around improving this and defining the logic followed.
As of v23.01, an item-level role permission override, with lack of permission (unchecked) will override and deny existing role/fallback permissions.
We still side towards allow though, where both allow and deny exist at the same permission specificity, which I know isn't what you'd prefer but it's how we've done permissions from the start so likely not something I'd look to change.
There's more details in the v23.01 blogpost and I also rant/describe permissions at about 7:22 in the accompanying release video.
Additionally, our docs have a new section to provide a high-level view of the logic defined and implemented.
@alanmcseveney commented on GitHub (Jan 31, 2023):
That's a real shame. Additive and subtractive options really are necessary, as demonstrated by their inclusion in all modern permissions models. Yes, we got by with POSIX (and still do) for many things, but in other places it's just not good enough and with Bookstack housing sensitive documentation for us (others too, I'm sure), a more robust approach to permissions would have been very welcome.
ACL's are present in all of these competing solutions:
Microsoft SharePoint - It provides a comprehensive ACL-based permissions model that allows administrators to control access to content at a very granular level.
Confluence - It also offers an ACL-based permissions model, allowing administrators to specify who does and does not have access to specific pages, spaces, or the entire platform.
MediaWiki - It has a flexible permissions model that can be configured to use ACLs, providing fine-grained control over user access to content.
Notion - It offers a flexible permissions model that can be configured to allow or restrict access to specific pages or databases, effectively implementing an ACL-based system.
@ssddanbrown commented on GitHub (Jan 31, 2023):
@alanmcseveney based on your comment, I'm not too sure what you want from BookStack's permission system to be honest, and what about the BookStack permission is not considered "robust". You can add an subtract permissions, we just default in a slightly different way to what you desire. From my perspective the permission options are already more ACL based than POSIX as your comment infers, and the options we provide are very similar to some of those platforms listed. The only significant thing we're maybe lacking right now in comparison is direct user-level permissions, since we do everything via roles really.
Also, keep in mind, that total funding of BookStack is probably less that a single junior developer at those large companies you're comparing us to. We do have to set our scope to what is reasonable to a certain degree.
@ssddanbrown commented on GitHub (Feb 18, 2023):
I'm going to proceed and close this off since, as explained above, we do now have some ability to deny permissions and I wouldn't look to expand the logical complexity of permissions beyond what we now support.