Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
penM000 opened this issue Aug 24, 2023 · 6 comments · Fixed by #13547
Closed
Assignees
Labels
severity: low Does not significantly disrupt application functionality, or a workaround is available status: accepted This issue has been accepted for implementation type: bug A confirmed report of unexpected behavior in the application

Comments

@penM000
Copy link

penM000 commented Aug 24, 2023

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.

@penM000 penM000 added the type: bug A confirmed report of unexpected behavior in the application label Aug 24, 2023
@abhi1693
Copy link
Member

abhi1693 commented 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 abhi1693 added the status: revisions needed This issue requires additional information to be actionable label Aug 24, 2023
@abhi1693
Copy link
Member

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 abhi1693 added status: needs owner This issue is tentatively accepted pending a volunteer committed to its implementation and removed status: revisions needed This issue requires additional information to be actionable labels Aug 24, 2023
@penM000
Copy link
Author

penM000 commented Aug 24, 2023

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

@abhi1693 abhi1693 self-assigned this Aug 24, 2023
@abhi1693 abhi1693 added status: accepted This issue has been accepted for implementation and removed status: needs owner This issue is tentatively accepted pending a volunteer committed to its implementation labels Aug 24, 2023
@jeremystretch
Copy link
Member

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 jeremystretch added status: under review Further discussion is needed to determine this issue's scope and/or implementation and removed status: accepted This issue has been accepted for implementation labels Aug 24, 2023
@penM000
Copy link
Author

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

@DanSheps
Copy link
Member

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.

@jeremystretch jeremystretch added status: accepted This issue has been accepted for implementation severity: low Does not significantly disrupt application functionality, or a workaround is available and removed status: under review Further discussion is needed to determine this issue's scope and/or implementation labels Aug 24, 2023
jeremystretch pushed a commit that referenced this issue Aug 24, 2023
* fixed permission for config context UI view #13543

* removed extras.view_configcontext permission #13543
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 23, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
severity: low Does not significantly disrupt application functionality, or a workaround is available status: accepted This issue has been accepted for implementation type: bug A confirmed report of unexpected behavior in the application
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants