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

Allow exclude object permission in 2.9 #3942

New Issue
Closed
opened 2025-12-29 18:32:11 +01:00 by adam · 11 comments
adam commented 2025-12-29 18:32:11 +01:00
Owner
Copy Link

Originally created by @a31amit on GitHub (Aug 4, 2020).

Environment

  • Python version: 3.8
  • NetBox version: 2.9-beta-1

Proposed Functionality

To Allow exclude() method on object permission along with filter()

Use Case

This change would allow us to protect information related to pre-released hardware where group belongs to tenant A can see everything else however very specific users for tenants would also able to see pre-released hardware information added to netbox specially Device Inventory tab.
At present with object permission, users can filter information but cannot use exclude()

Example -
Assume you have 20-40 items in inventory tab such as cpu/ ram/ disk / gpu and so on. if we wanted to exclude only 1 or 2 inventory items, we have to create filters for all to display so remaining items not included in filter() don't show up.

That means users will end up creating filter for each inventory item. but if Django query exclude() support with netbox, than we can just add what to exclude but remaining would show up.

We record some Pre-Released hardware information netbox inventory tab. this is a very important feature where we can allow users to see most of the inventory items but very specific people can query or see pre-released hw info

Database Changes

Not sure

External Dependencies

Should be none as Object Permission is core feature of netbox

Originally created by @a31amit on GitHub (Aug 4, 2020). <!-- NOTE: IF YOUR ISSUE DOES NOT FOLLOW THIS TEMPLATE, IT WILL BE CLOSED. This form is only for proposing specific new features or enhancements. If you have a general idea or question, please post to our mailing list instead of opening an issue: https://groups.google.com/forum/#!forum/netbox-discuss NOTE: Due to an excessive backlog of feature requests, we are not currently accepting any proposals which significantly extend NetBox's feature scope. Please describe the environment in which you are running NetBox. Be sure that you are running an unmodified instance of the latest stable release before submitting a bug report. --> ### Environment * Python version: 3.8 * NetBox version: 2.9-beta-1 <!-- Describe in detail the new functionality you are proposing. Include any specific changes to work flows, data models, or the user interface. --> ### Proposed Functionality To Allow exclude() method on object permission along with filter() <!-- Convey an example use case for your proposed feature. Write from the perspective of a NetBox user who would benefit from the proposed functionality and describe how. ---> ### Use Case This change would allow us to protect information related to pre-released hardware where group belongs to tenant A can see everything else however very specific users for tenants would also able to see pre-released hardware information added to netbox specially Device Inventory tab. At present with object permission, users can filter information but cannot use exclude() Example - Assume you have 20-40 items in inventory tab such as cpu/ ram/ disk / gpu and so on. if we wanted to exclude only 1 or 2 inventory items, we have to create filters for all to display so remaining items not included in filter() don't show up. That means users will end up creating filter for each inventory item. but if Django query exclude() support with netbox, than we can just add what to exclude but remaining would show up. We record some Pre-Released hardware information netbox inventory tab. this is a very important feature where we can allow users to see most of the inventory items but very specific people can query or see pre-released hw info <!-- Note any changes to the database schema necessary to support the new feature. For example, does the proposal require adding a new model or field? (Not all new features require database changes.) ---> ### Database Changes Not sure <!-- List any new dependencies on external libraries or services that this new feature would introduce. For example, does the proposal require the installation of a new Python package? (Not all new features introduce new dependencies.) --> ### External Dependencies Should be none as Object Permission is core feature of netbox
adam added the type: featurepending closurestatus: under review labels 2025-12-29 18:32:11 +01:00
adam closed this issue 2025-12-29 18:32:11 +01:00
adam commented 2025-12-29 18:32:12 +01:00
Author
Owner
Copy Link

@lampwins commented on GitHub (Aug 4, 2020):

@jeremystretch will need to comment on the viability of this. My opinion would be to not do this as it basically equates to access controls based on a blacklist, which can be very dangerous if not properly understood. I would want to push this in the direction of using a pre-release tag on inventory items which would require us to support tags there as a separate issue.

@lampwins commented on GitHub (Aug 4, 2020): @jeremystretch will need to comment on the viability of this. My opinion would be to not do this as it basically equates to access controls based on a blacklist, which can be very dangerous if not properly understood. I would want to push this in the direction of using a `pre-release` tag on inventory items which would require us to support tags there as a separate issue.
adam commented 2025-12-29 18:32:12 +01:00
Author
Owner
Copy Link

@lampwins commented on GitHub (Aug 4, 2020):

Clarification, we do actually support tags on inventory items, just not on the creation form, which is really a bug.

@lampwins commented on GitHub (Aug 4, 2020): Clarification, we do actually support tags on inventory items, just not on the creation form, which is really a bug.
adam commented 2025-12-29 18:32:12 +01:00
Author
Owner
Copy Link

@lampwins commented on GitHub (Aug 4, 2020):

And is already fixed in 2.9. I'm new here :)

@lampwins commented on GitHub (Aug 4, 2020): And is already fixed in 2.9. I'm new here :)
adam commented 2025-12-29 18:32:12 +01:00
Author
Owner
Copy Link

@a31amit commented on GitHub (Aug 4, 2020):

I am still not sure if without exclude or control based on a blacklist such cases even possible. but I believe blacklist or exclude would be having same impact as filter. when you do blacklist, you know exactly what you blacklisted, with filters it's even more concerned because there would be a lot of permission with filter OR statement which can easily be missed out.

@a31amit commented on GitHub (Aug 4, 2020): I am still not sure if without exclude or control based on a blacklist such cases even possible. but I believe blacklist or exclude would be having same impact as filter. when you do blacklist, you know exactly what you blacklisted, with filters it's even more concerned because there would be a lot of permission with filter OR statement which can easily be missed out.
adam commented 2025-12-29 18:32:12 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 5, 2020):

when you do blacklist, you know exactly what you blacklisted

You know exactly what you've blacklisted, but not what you've neglected to blacklist. This is @lampwins' point: It's much easier to audit what access has been specifically allowed, as opposed to ensuring everything that shouldn't be allowed has been blocked. A blacklist-based approach fails in an non-secure fashion, as opposed to a whitelist which denies access by default.

That said, I can see a use case for the inversion. It could be as simple as implementing an "invert" checkbox on the ObjectPermission model which, when applied, calls exclude() with the prescribed constraints rather than include(). We'd just need to make it very clear to the user that the length of rope he or she is being issued is more than enough to hang oneself.

@jeremystretch commented on GitHub (Aug 5, 2020): > when you do blacklist, you know exactly what you blacklisted You know exactly what you've blacklisted, but not what you've _neglected_ to blacklist. This is @lampwins' point: It's much easier to audit what access has been specifically allowed, as opposed to ensuring everything that shouldn't be allowed has been blocked. A blacklist-based approach fails in an non-secure fashion, as opposed to a whitelist which denies access by default. That said, I can see a use case for the inversion. It could be as simple as implementing an "invert" checkbox on the ObjectPermission model which, when applied, calls `exclude()` with the prescribed constraints rather than `include()`. We'd just need to make it _very_ clear to the user that the length of rope he or she is being issued is more than enough to hang oneself.
adam commented 2025-12-29 18:32:12 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Aug 7, 2020):

I've looked into this a bit further, but I'm a little stuck at how we'd efficiently convey the negation of constraints when caching assigned permissions on the user instance. The current approach results in a dictionary similar to the following:

{
    'ipam.view_vlan': [
        {'vid__gte': 100, 'vid__lt': 200},
        {'status': 'reserved'}
    ],
    'dcim.view_site': [
        {'name__startswith': 'foo'}
    ],
    'dcim.view_region': [None]
}

In this example, the user can view VLANs and sites with some constraints, and can view all regions.

I like this arrangement because we can check for the existence of a specific permission as a dictionary key to quickly determine whether the user has that permission on at least some objects (if the user did not, the key would not exist). This is handy for things like disabling navigation menu items.

To support negation for permission constraints, we'll need to come up with an elegant way to convey the inversion when caching permissions, ideally while maintaining the current dictionary-based approach.

@jeremystretch commented on GitHub (Aug 7, 2020): I've looked into this a bit further, but I'm a little stuck at how we'd efficiently convey the negation of constraints when caching assigned permissions on the user instance. The current approach results in a dictionary similar to the following: ``` { 'ipam.view_vlan': [ {'vid__gte': 100, 'vid__lt': 200}, {'status': 'reserved'} ], 'dcim.view_site': [ {'name__startswith': 'foo'} ], 'dcim.view_region': [None] } ``` In this example, the user can view VLANs and sites with some constraints, and can view _all_ regions. I like this arrangement because we can check for the existence of a specific permission as a dictionary key to quickly determine whether the user has that permission on at least _some_ objects (if the user did not, the key would not exist). This is handy for things like disabling navigation menu items. To support negation for permission constraints, we'll need to come up with an elegant way to convey the inversion when caching permissions, ideally while maintaining the current dictionary-based approach.
adam commented 2025-12-29 18:32:12 +01:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Oct 7, 2020):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our contributing guide.

@stale[bot] commented on GitHub (Oct 7, 2020): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 18:32:12 +01:00
Author
Owner
Copy Link

@a31amit commented on GitHub (Oct 7, 2020):

@jeremystretch - Can we Please exclude this from auto-remove stale bot. I still believe this feature would be very useful and wish to get implemented in core. lately noticing that auto stale-bot seems closing many outstanding issues.

@a31amit commented on GitHub (Oct 7, 2020): @jeremystretch - Can we Please exclude this from auto-remove stale bot. I still believe this feature would be very useful and wish to get implemented in core. lately noticing that auto stale-bot seems closing many outstanding issues.
adam commented 2025-12-29 18:32:12 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 7, 2020):

@a31amit sorry, but it doesn't look like there's been any further interest in it from the community, and the development effort it would demand honestly isn't going to be worthwhile.

lately noticing that auto stale-bot seems closing many outstanding issues.

Yes; that's its purpose. Issues which don't receive continued interest and for which no one volunteers to implement get closed so that development can remain focused.

@jeremystretch commented on GitHub (Oct 7, 2020): @a31amit sorry, but it doesn't look like there's been any further interest in it from the community, and the development effort it would demand honestly isn't going to be worthwhile. > lately noticing that auto stale-bot seems closing many outstanding issues. Yes; that's its purpose. Issues which don't receive continued interest and for which no one volunteers to implement get closed so that development can remain focused.
adam commented 2025-12-29 18:32:12 +01:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Oct 23, 2020):

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

@stale[bot] commented on GitHub (Oct 23, 2020): This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.
adam commented 2025-12-29 18:32:12 +01:00
Author
Owner
Copy Link

@hballiance commented on GitHub (Dec 4, 2020):

+1

This would be useful for us. For example I want to restrict access for a group of users. Allow them access to all devices that contain "aaa" in name however exclude ones that also contain "bbb" in name. The following should happen...

  • Device: "aaa-ccc-123" > Allow
  • Device "aaa-bbb-123" > Deny
@hballiance commented on GitHub (Dec 4, 2020): +1 This would be useful for us. For example I want to restrict access for a group of users. Allow them access to all devices that contain "aaa" in name however exclude ones that also contain "bbb" in name. The following should happen... - Device: "aaa-ccc-123" > Allow - Device "aaa-bbb-123" > Deny
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 pending closure status: under review type: feature
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#3942
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?