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

Permissions constraints not working for MAC Address objects #11291

New Issue
Closed
opened 2025-12-29 21:43:06 +01:00 by adam · 6 comments
adam commented 2025-12-29 21:43:06 +01:00
Owner
Copy Link

Originally created by @dhoffend on GitHub (Jun 18, 2025).

Deployment Type

Self-hosted

NetBox Version

v.4.3.1

Python Version

3.11

Steps to Reproduce

  1. Create Permission
  2. Select DCIM | MAC Address
  3. Set Constraints to {"assigned_object__device__tenant__name": "sometenantname"} or parent or virtual_machine or whatever

Expected Behavior

The ability to limit the add/view/edit/delete access to mac addresses that matches the permissions constraints

Observed Behavior

With the introduction of handling multiple MAC adresses per interface in v4.2 the mac address field was moved away from the device.interface into its own object.

Before v4.2 we could limit the object level permissions on interface level to restrict them to a tenant, site or other constraint settings. Starting with v4.2 we can't limit the access and people would be able to add/view/edit/delete mac addresses of devices they shouldn't have access too.

I consider this as a bug, cause before 4.2 we could limit the permissions on in interface level and now it's broken, no longer exists, not working due to internal missing relations.

Originally created by @dhoffend on GitHub (Jun 18, 2025). ### Deployment Type Self-hosted ### NetBox Version v.4.3.1 ### Python Version 3.11 ### Steps to Reproduce 1. Create Permission 2. Select DCIM | MAC Address 3. Set Constraints to `{"assigned_object__device__tenant__name": "sometenantname"}` or parent or virtual_machine or whatever ### Expected Behavior The ability to limit the add/view/edit/delete access to mac addresses that matches the permissions constraints ### Observed Behavior With the introduction of handling multiple MAC adresses per interface in v4.2 the mac address field was moved away from the `device.interface` into its own object. Before v4.2 we could limit the object level permissions on interface level to restrict them to a tenant, site or other constraint settings. Starting with v4.2 we can't limit the access and people would be able to add/view/edit/delete mac addresses of devices they shouldn't have access too. I consider this as a bug, cause before 4.2 we could limit the permissions on in interface level and now it's broken, no longer exists, not working due to internal missing relations.
adam added the type: bug label 2025-12-29 21:43:06 +01:00
adam closed this issue 2025-12-29 21:43:06 +01:00
adam commented 2025-12-29 21:43:07 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (Sep 17, 2025):

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. Do not attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our contributing guide.

@github-actions[bot] commented on GitHub (Sep 17, 2025): 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. **Do not** attempt to circumvent this process by "bumping" the issue; doing so will result in its immediate closure and you may be barred from participating in any future discussions. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/main/CONTRIBUTING.md).
adam commented 2025-12-29 21:43:07 +01:00
Author
Owner
Copy Link

@bctiemann commented on GitHub (Oct 9, 2025):

@dhoffend After some digging into this, I found that the existing permissions ORM lookup interface__device__tenant__name (or vminterface__) works without any code changes. Could you please recheck whether that serves the purpose here?

@bctiemann commented on GitHub (Oct 9, 2025): @dhoffend After some digging into this, I found that the existing permissions ORM lookup `interface__device__tenant__name` (or `vminterface__`) works without any code changes. Could you please recheck whether that serves the purpose here?
adam commented 2025-12-29 21:43:07 +01:00
Author
Owner
Copy Link

@bctiemann commented on GitHub (Oct 10, 2025):

Closing as this appears to be working as intended, as long as you know the secret incantation for the lookup as above. Maybe some documentation would be warranted.

@bctiemann commented on GitHub (Oct 10, 2025): Closing as this appears to be working as intended, as long as you know the secret incantation for the lookup as above. Maybe some documentation would be warranted.
adam commented 2025-12-29 21:43:08 +01:00
Author
Owner
Copy Link

@dhoffend commented on GitHub (Nov 12, 2025):

@bctiemann I just tested the hint to the already existing interface relation as @jnovinger mentiond in the review of #20486

At first it seems to work, but it's possible that's there a problem because of relations to different models.

Here's an example from the nbshell using the current stable release v4.4.6:

In my instance, I've created 2 mac address objects. One assigned to virtual_machine interface and one assigned to physical device interface.

### NetBox interactive shell (hostname)
### Python v3.11.2 | Django v5.2.8 | NetBox Community v4.4.6
### Plugins: netbox_dns v1.4.3
### lsapps() & lsmodels() will show available models. Use help(<model>) for more info.

>>> m = dcim.MACAddress.objects.get(pk=2)
>>> m.mac_address
EUI('00:11:22:33:44:55')
>>> m.assigned_object.name
'eth0'
>>> m.assigned_object.virtual_machine.name
'testvm'

>>> m = dcim.MACAddress.objects.get(pk=3)
>>> m.mac_address
EUI('11:22:33:44:55:66')
>>> m.assigned_object.name
'eth0'
>>> m.assigned_object.device.name
'testhw'

>>> dcim.MACAddress.objects.filter(interface__name="eth0")
<RestrictedQuerySet [<MACAddress: 11:22:33:44:55:66>]>

>>> dcim.MACAddress.objects.filter(interface__name="eth0").count()
1

It looks like there's still a problem in the interface relation filter.

@dhoffend commented on GitHub (Nov 12, 2025): @bctiemann I just tested the hint to the already existing `interface` relation as @jnovinger mentiond in the review of #20486 At first it seems to work, but it's possible that's there a problem because of relations to different models. Here's an example from the `nbshell` using the current stable release `v4.4.6`: In my instance, I've created 2 mac address objects. One assigned to virtual_machine interface and one assigned to physical device interface. ``` ### NetBox interactive shell (hostname) ### Python v3.11.2 | Django v5.2.8 | NetBox Community v4.4.6 ### Plugins: netbox_dns v1.4.3 ### lsapps() & lsmodels() will show available models. Use help(<model>) for more info. >>> m = dcim.MACAddress.objects.get(pk=2) >>> m.mac_address EUI('00:11:22:33:44:55') >>> m.assigned_object.name 'eth0' >>> m.assigned_object.virtual_machine.name 'testvm' >>> m = dcim.MACAddress.objects.get(pk=3) >>> m.mac_address EUI('11:22:33:44:55:66') >>> m.assigned_object.name 'eth0' >>> m.assigned_object.device.name 'testhw' >>> dcim.MACAddress.objects.filter(interface__name="eth0") <RestrictedQuerySet [<MACAddress: 11:22:33:44:55:66>]> >>> dcim.MACAddress.objects.filter(interface__name="eth0").count() 1 ``` It looks like there's still a problem in the interface relation filter.
adam commented 2025-12-29 21:43:08 +01:00
Author
Owner
Copy Link

@dhoffend commented on GitHub (Nov 12, 2025):

My guess: the following relations should be moved from class Interface to BaseInterface since macs, ips, fhrp groups, vrf, etc applies to virtual machines as well ...

I would go even further and move tunnel and l2vpn relations to BaseInterface as well ... with virtual firewall and routing appliances this is also a valid point. Especially when you can create tunnels in netbox and decide if your Termination is a virtual machine or device

@dhoffend commented on GitHub (Nov 12, 2025): My guess: the following relations should be moved from class `Interface` to `BaseInterface` since macs, ips, fhrp groups, vrf, etc applies to virtual machines as well ... I would go even further and move tunnel and l2vpn relations to BaseInterface as well ... with virtual firewall and routing appliances this is also a valid point. Especially when you can create tunnels in netbox and decide if your Termination is a virtual machine or device
adam commented 2025-12-29 21:43:08 +01:00
Author
Owner
Copy Link

@dhoffend commented on GitHub (Nov 13, 2025):

Okay, forget everything what I just said ... every relation was already part of the VMInterface object. I just didn't read the vminterface__ filterstatement and was looking into the wrong file.

Here's the example, if somebody stumbles across this ticket

>>> dcim.MACAddress.objects.filter(vminterface__name="eth0")
<RestrictedQuerySet [<MACAddress: 00:11:22:33:44:55>]>

>>> dcim.MACAddress.objects.filter(interface__name="eth0")
<RestrictedQuerySet [<MACAddress: 11:22:33:44:55:66>]>

Everything works fine. Thanks for pointing it out

@dhoffend commented on GitHub (Nov 13, 2025): Okay, forget everything what I just said ... every relation was already part of the `VMInterface` object. I just didn't read the `vminterface__` filterstatement and was looking into the wrong file. Here's the example, if somebody stumbles across this ticket ``` >>> dcim.MACAddress.objects.filter(vminterface__name="eth0") <RestrictedQuerySet [<MACAddress: 00:11:22:33:44:55>]> >>> dcim.MACAddress.objects.filter(interface__name="eth0") <RestrictedQuerySet [<MACAddress: 11:22:33:44:55:66>]> ``` Everything works fine. Thanks for pointing it out
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 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#11291
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?