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

[penM000]

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.
   
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.
   

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

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

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

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

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.

[abhi1693]

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.

[abhi1693]

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.

[penM000]

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

[jeremystretch]

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:

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.