starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-12 05:20:31 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Constraints not fully honored #9655

New Issue
Closed
opened 2025-12-29 21:20:29 +01:00 by adam · 1 comment
adam commented 2025-12-29 21:20:29 +01:00
Owner
Copy Link

Originally created by @chaydock on GitHub (May 12, 2024).

Deployment Type

Self-hosted

NetBox Version

v3.7.4

Python Version

3.10

Steps to Reproduce

I've created numerous permission constraints for a user (25 permissions in all) to lock down what they can/cannot see. As an example, one of the permissions is viewing DCIM.Devices with a constraint of [{"site__group_id": "5"}, {"tenant_id": "8"}] which when applied restricts them to seeing only the devices for their assigned site or tenant status. (I could post the full custom script I ultimately made to rapidly create each permission for new users if it would be of any help.)

Expected Behavior

The expectation is that when the multiple permissions are applied that the user will only be able to see items to which they are assigned. In particular even on pages that show summary information of those items such as device totals.

Observed Behavior

In large, the permissions work as intended when applied when they click directly into an area that has the restriction. As the example above... when they click into the devices section, the only devices that they see are those which the constraint limits them to. HOWEVER, there are other spots that a different query is running that does not honor the assigned constraints. As an example, if they go to a section like "Device Types" where they can see not only all of the device types, but also the quantity of devices of that type... they see a quantity listed for EVERY instance in the entire database and not just the quantity that they have access to. This happens in numerous places in the interface where there is a quantity listed for some object. On the upshot... when they click on the quantity number, it loads the associated page with only the objects they have permissions for. This is however a bit confusing for the user for some screens. In most cases they just have fewer quantity than what they actually have access to (which is bad enough), or in the case above where they might click on a quantity that they have zero access to and that's bad because it looks like the program is broken.

For the record, for the above example, the Device Type permission is set to view with no constraint so that the user can see all the types that are available. I thought initially that perhaps adding a constraint to that as well would solve the problem. However, when the added constraint is added, it simply narrows the full list to types that have devices assigned to the user.... and the number of devices for that type still shows ALL devices of that type... not the quantity of devices that the user is constrained to having permissions for.

I could probably live with the above if the quantity listed was the only issue. But, the part where it gets really bad is when using the plugin for topology. If a user sets a very basic filter like just showing logical connections and nothing else... then the resultant topology shows EVERYTHING in the entire database with a connection and none of the user's constraints are being honored. Furthermore, if they hover on the object in the topology view they get access to quite a bit of data in the pop-up window that they shouldn't have access to. Double clicking the object which directs them to the object's page will give them the permission error if they don't legitimately have rights to see the object details. But, the object should have never been rendered in the topology view in the first place. Similar IMHO to how the quantity number listed shows everything when it should have been limited to only what they have access to.

I know that the topology view issue may very well be a bug with that specific plugin rather than the core functionality of the NetBox constraints. However, given the other breaches in being able to "see more than they should" (the quantity fields being incorrect given the applied constraints), I felt that these two may be related somehow and that I should share the full experience. I also know that I'm not running the latest release of NetBox... and perhaps the issue has been fixed already in a subsequent release (I didn't notice any mention of it in any of the release notes though). But, I am working through an issue with the upgrade right now that's preventing me from upgrading to verify. That said, if it has been fixed... feel free to close this bug report.

Originally created by @chaydock on GitHub (May 12, 2024). ### Deployment Type Self-hosted ### NetBox Version v3.7.4 ### Python Version 3.10 ### Steps to Reproduce I've created numerous permission constraints for a user (25 permissions in all) to lock down what they can/cannot see. As an example, one of the permissions is viewing DCIM.Devices with a constraint of [{"site__group_id": "5"}, {"tenant_id": "8"}] which when applied restricts them to seeing only the devices for their assigned site or tenant status. (I could post the full custom script I ultimately made to rapidly create each permission for new users if it would be of any help.) ### Expected Behavior The expectation is that when the multiple permissions are applied that the user will only be able to see items to which they are assigned. In particular even on pages that show summary information of those items such as device totals. ### Observed Behavior In large, the permissions work as intended when applied when they click directly into an area that has the restriction. As the example above... when they click into the devices section, the only devices that they see are those which the constraint limits them to. HOWEVER, there are other spots that a different query is running that does not honor the assigned constraints. As an example, if they go to a section like "Device Types" where they can see not only all of the device types, but also the quantity of devices of that type... they see a quantity listed for EVERY instance in the entire database and not just the quantity that they have access to. This happens in numerous places in the interface where there is a quantity listed for some object. On the upshot... when they click on the quantity number, it loads the associated page with only the objects they have permissions for. This is however a bit confusing for the user for some screens. In most cases they just have fewer quantity than what they actually have access to (which is bad enough), or in the case above where they might click on a quantity that they have zero access to and that's bad because it looks like the program is broken. For the record, for the above example, the Device Type permission is set to view with no constraint so that the user can see all the types that are available. I thought initially that perhaps adding a constraint to that as well would solve the problem. However, when the added constraint is added, it simply narrows the full list to types that have devices assigned to the user.... and the number of devices for that type still shows ALL devices of that type... not the quantity of devices that the user is constrained to having permissions for. I could probably live with the above if the quantity listed was the only issue. But, the part where it gets really bad is when using the plugin for topology. If a user sets a very basic filter like just showing logical connections and nothing else... then the resultant topology shows EVERYTHING in the entire database with a connection and none of the user's constraints are being honored. Furthermore, if they hover on the object in the topology view they get access to quite a bit of data in the pop-up window that they shouldn't have access to. Double clicking the object which directs them to the object's page will give them the permission error if they don't legitimately have rights to see the object details. But, the object should have never been rendered in the topology view in the first place. Similar IMHO to how the quantity number listed shows everything when it should have been limited to only what they have access to. I know that the topology view issue may very well be a bug with that specific plugin rather than the core functionality of the NetBox constraints. However, given the other breaches in being able to "see more than they should" (the quantity fields being incorrect given the applied constraints), I felt that these two may be related somehow and that I should share the full experience. I also know that I'm not running the latest release of NetBox... and perhaps the issue has been fixed already in a subsequent release (I didn't notice any mention of it in any of the release notes though). But, I am working through an issue with the upgrade right now that's preventing me from upgrading to verify. That said, if it has been fixed... feel free to close this bug report.
adam closed this issue 2025-12-29 21:20:29 +01:00
adam commented 2025-12-29 21:20:29 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (May 13, 2024):

As an example, if they go to a section like "Device Types" where they can see not only all of the device types, but also the quantity of devices of that type... they see a quantity listed for EVERY instance in the entire database and not just the quantity that they have access to.

This is how the current implementation of NetBox's object-based permissions system is intended to function: The goal of the feature is to prevent a user from accessing the details of an object, not to pretend that it does not exist. (The later would be practically impossible to enforce in such a complex system with myriad relationships among dozens of models.) Still, if you would like to spend some time experimenting with how it might be improved, you're welcome to submit a feature request detailing your proposed changes.

I know that the topology view issue may very well be a bug with that specific plugin rather than the core functionality of the NetBox constraints.

Correct. For any bugs or feature requests involving a plugin, please follow the specific plugin's contributing policy to raise the issue with its maintainer(s), as these are out of scope for the core NetBox project.

@jeremystretch commented on GitHub (May 13, 2024): > As an example, if they go to a section like "Device Types" where they can see not only all of the device types, but also the quantity of devices of that type... they see a quantity listed for EVERY instance in the entire database and not just the quantity that they have access to. This is how the current implementation of NetBox's object-based permissions system is intended to function: The goal of the feature is to prevent a user from accessing the details of an object, not to pretend that it does not exist. (The later would be practically impossible to enforce in such a complex system with myriad relationships among dozens of models.) Still, if you would like to spend some time experimenting with how it might be improved, you're welcome to submit a feature request detailing your proposed changes. > I know that the topology view issue may very well be a bug with that specific plugin rather than the core functionality of the NetBox constraints. Correct. For any bugs or feature requests involving a plugin, please follow the specific plugin's contributing policy to raise the issue with its maintainer(s), as these are out of scope for the core NetBox project.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#9655
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?