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

A problem where information can be read even though read permissions have not been granted. #8506

New Issue
Closed
opened 2025-12-29 20:37:34 +01:00 by adam · 6 comments
adam commented 2025-12-29 20:37:34 +01:00
Owner
Copy Link

Originally created by @penM000 on GitHub (Aug 24, 2023).

Originally assigned to: @abhi1693 on GitHub.

NetBox version

v3.5.5

Python version

3.10

Steps to Reproduce

  1. Create a user (in this case, test) who has not been granted any access rights. When he logs in, he will not be able to see the dashboard or anything else.
    image
  2. Grant read permission to this user by assigning him to a group. Here, we grant all read permissions to DCIM.
cable, cable path, console port, console port template, console server port, console server port template, device, device bay, device bay template, device role, device type, front port, front port template, interface, interface template, inventory item, location, manufacturer, platform, power feed, power outlet, power outlet template, power panel, power port, power port template, rack, rack reservation, rack role, rear port, rear port template, region, site, site group, virtual chassis, module type, module bay, module, module bay template, inventory item role, inventory item template, cable termination, virtual device context

  1. Reload the page after granting, and some items will become viewable.
    image

  2. Open the appropriate device. The "Config Context" permission is not granted, so it is not shown in the tab.
    image

  3. Add "config-context/" to the current URL. In the image example, "https://netbox/dcim/devices/3009/config-context/"
    image
    image

6.Check the api page. You will see the "Config Context" section.
image

7.I do not have access to "https://netbox/extras/config-contexts/".
image

Expected Behavior

If you hit the URL directly, expect to see "You do not have permission to access this page.
We also expect that the API will not display any information that you do not have permission to access.

Observed Behavior

Users who do not have permissions to read the "Config Context" behave in such a way that the corresponding page and the "Config Context" of the "Device" are hidden.
However, in reality, this is visible by directly hitting the API or URL.
We believe this is a bug that allows users to read the "Config Context" information even though they do not have read permission.

Originally created by @penM000 on GitHub (Aug 24, 2023). Originally assigned to: @abhi1693 on GitHub. ### NetBox version v3.5.5 ### Python version 3.10 ### Steps to Reproduce 1. Create a user (in this case, test) who has not been granted any access rights. When he logs in, he will not be able to see the dashboard or anything else. ![image](https://github.com/netbox-community/netbox/assets/33054826/32b64f75-853e-4794-8b82-98184a3e258a) 2. Grant read permission to this user by assigning him to a group. Here, we grant all read permissions to DCIM. ``` cable, cable path, console port, console port template, console server port, console server port template, device, device bay, device bay template, device role, device type, front port, front port template, interface, interface template, inventory item, location, manufacturer, platform, power feed, power outlet, power outlet template, power panel, power port, power port template, rack, rack reservation, rack role, rear port, rear port template, region, site, site group, virtual chassis, module type, module bay, module, module bay template, inventory item role, inventory item template, cable termination, virtual device context ``` 3. Reload the page after granting, and some items will become viewable. ![image](https://github.com/netbox-community/netbox/assets/33054826/896141a3-c045-404d-a464-fdd2f036ecda) 4. Open the appropriate device. The "Config Context" permission is not granted, so it is not shown in the tab. ![image](https://github.com/netbox-community/netbox/assets/33054826/dbc592c8-4626-4c0f-97bc-93393b4fcc42) 5. Add "config-context/" to the current URL. In the image example, "https://netbox/dcim/devices/3009/config-context/" ![image](https://github.com/netbox-community/netbox/assets/33054826/cb9702f3-669a-40ef-a9ef-b5de941cd3ed) ![image](https://github.com/netbox-community/netbox/assets/33054826/8f81842b-8490-4075-8596-094f86675c36) 6.Check the api page. You will see the "Config Context" section. ![image](https://github.com/netbox-community/netbox/assets/33054826/8e2da802-0ae5-4cd9-bf80-0b0fd16e6c6a) 7.I do not have access to "https://netbox/extras/config-contexts/". ![image](https://github.com/netbox-community/netbox/assets/33054826/4f204699-6e6b-472a-bfdb-8f521bc4a46b) ### Expected Behavior If you hit the URL directly, expect to see "You do not have permission to access this page. We also expect that the API will not display any information that you do not have permission to access. ### Observed Behavior Users who do not have permissions to read the "Config Context" behave in such a way that the corresponding page and the "Config Context" of the "Device" are hidden. However, in reality, this is visible by directly hitting the API or URL. We believe this is a bug that allows users to read the "Config Context" information even though they do not have read permission.
adam added the type: bugstatus: acceptedseverity: low labels 2025-12-29 20:37:34 +01:00
adam closed this issue 2025-12-29 20:37:34 +01:00
adam commented 2025-12-29 20:37:34 +01:00
Author
Owner
Copy Link

@abhi1693 commented on GitHub (Aug 24, 2023):

Thank you for opening a bug report. I was unable to reproduce the reported behavior on NetBox v3.5.8. Please re-confirm the reported behavior on the current stable release and adjust your post above as necessary. Remember to provide detailed steps that someone else can follow using a clean installation of NetBox to reproduce the issue. Remember to include the steps taken to create any initial objects or other data.

To add more context, I created a user with 0 permissions and 0 groups and also did not provide any staff/superuser access.

image

@abhi1693 commented on GitHub (Aug 24, 2023): Thank you for opening a bug report. I was unable to reproduce the reported behavior on NetBox v3.5.8. Please re-confirm the reported behavior on the current stable release and adjust your post above as necessary. Remember to provide detailed steps that someone else can follow using a clean installation of NetBox to reproduce the issue. Remember to include the steps taken to create any initial objects or other data. To add more context, I created a user with 0 permissions and 0 groups and also did not provide any staff/superuser access. ![image](https://github.com/netbox-community/netbox/assets/5083532/5e467ad2-1550-4511-b99a-95e10f9818dd)
adam commented 2025-12-29 20:37:35 +01:00
Author
Owner
Copy Link

@abhi1693 commented on GitHub (Aug 24, 2023):

You did not mention that your user had other permissions like read on several other components of the device and on itself and hence was unclear on what permissions should I provide other than not providing the one you mentioned. Please update your post above to clearly mention this distinction as well.

@abhi1693 commented on GitHub (Aug 24, 2023): You did not mention that your user had other permissions like `read` on several other components of the device and on itself and hence was unclear on what permissions should I provide other than not providing the one you mentioned. Please update your post above to clearly mention this distinction as well.
adam commented 2025-12-29 20:37:35 +01:00
Author
Owner
Copy Link

@penM000 commented on GitHub (Aug 24, 2023):

The first post has been updated. Please check back.
I will try v3.5.8 tomorrow.

@penM000 commented on GitHub (Aug 24, 2023): The first post has been updated. Please check back. I will try v3.5.8 tomorrow.
adam commented 2025-12-29 20:37:35 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 24, 2023):

There's an important distinction being overlooked here. Permissions relating to the ConfigContext model pertain to the config context objects themselves, not the rendered context for a given device or VM. This is best conveyed by this screenshot from above:

Screenshot

Note that the rendered context is displayed, but the source contexts - the actual ConfigContext objects - are not.

There is a bug insofar as the "config context" tab under the device view is hidden but the view remains accessible; this is obviously inconsistent. However, I reject the assertion that the extras.view_configcontext permission should control access to a device's rendered context, as this is different from raw ConfigContext data and would deviate from the object-based permissions model.

I believe the fix here is to not condition display of the "config context" tab on the extras.view_configcontext permission (which was likely done as an oversight originally). If there's a need to restrict a user's access to the rendered context for a particular object, then a feature request should be submitted to propose a new permission for doing so.

@jeremystretch commented on GitHub (Aug 24, 2023): There's an important distinction being overlooked here. Permissions relating to the ConfigContext model pertain to the config context objects themselves, _not_ the rendered context for a given device or VM. This is best conveyed by this screenshot from above: ![Screenshot](https://user-images.githubusercontent.com/33054826/262965317-cb9702f3-669a-40ef-a9ef-b5de941cd3ed.png) Note that the rendered context is displayed, but the source contexts - the actual ConfigContext objects - are not. There is a bug insofar as the "config context" tab under the device view is hidden but the view remains accessible; this is obviously inconsistent. However, I reject the assertion that the `extras.view_configcontext` permission should control access to a device's rendered context, as this is different from raw ConfigContext data and would deviate from the object-based permissions model. I believe the fix here is to _not_ condition display of the "config context" tab on the `extras.view_configcontext` permission (which was likely done as an oversight originally). If there's a need to restrict a user's access to the _rendered_ context for a particular object, then a feature request should be submitted to propose a new permission for doing so.
adam commented 2025-12-29 20:37:35 +01:00
Author
Owner
Copy Link

@penM000 commented on GitHub (Aug 24, 2023):

I understand that the behavior of the "config context" tab being hidden under the device view is more of a bug.
However, since this behavior also occurred in nautobot, I assume that this has been happening since version 2 of netbox.
Until now, netbox provided access to the config context tab under the device view via extras.view_configcontext.
I have a modification that shows the "config context" tab regardless of the status of extras.view_configcontext,
I believe that this behavior may affect the intended users.

In light of this implication, I believe a discussion is needed as to whether this feature should be added.

@penM000 commented on GitHub (Aug 24, 2023): I understand that the behavior of the "config context" tab being hidden under the device view is more of a bug. However, since this behavior also occurred in nautobot, I assume that this has been happening since version 2 of netbox. Until now, netbox provided access to the config context tab under the device view via extras.view_configcontext. I have a modification that shows the "config context" tab regardless of the status of extras.view_configcontext, I believe that this behavior may affect the intended users. In light of this implication, I believe a discussion is needed as to whether this feature should be added.
adam commented 2025-12-29 20:37:35 +01:00
Author
Owner
Copy Link

@DanSheps commented on GitHub (Aug 24, 2023):

I am in agreement here that the tab should be visible based on the person's ability to view the device itself.

I think if there is a need to restrict render context data view, a new FR should be opened to discuss that.

@DanSheps commented on GitHub (Aug 24, 2023): I am in agreement here that the tab should be visible based on the person's ability to view the device itself. I think if there is a need to restrict render context data view, a new FR should be opened to discuss that.
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 severity: low status: accepted type: bug
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#8506
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?