API access to render-config needs add permissions and write enable for the api token

[jiuka]

Deployment Type

Self-hosted

NetBox Version

v3.6.8

Python Version

3.10

Steps to Reproduce

1. Create a User with View Permissions to all Object Types
2. Create a API key for this User with out Wrire Enabled
3. Create a Device (No configured render config is needed to trigger this bug)
4. Try to use the dcim_devices_render_config_create API Endpoint with the created API key / user

Expected Behavior

The User with Read Access to the Device should be able to get the render config from the API. As there is no config set a No config template found for this device error is expected.

user@host:~$ curl -H 'Authorization: Token <YOURTOKEN>' https://netbox/api/dcim/devices/<ID>/render-config/
{"error":"No config template found for this device."}

Observed Behavior

The User with Read Access to the Device has no permission to access the render config from the API.

user@host:~$ curl -H 'Authorization: Token <YOURTOKEN>' https://netbox/api/dcim/devices/<ID>/render-config/
{"detail":"You do not have permission to perform this action."}

If the user is granted add permissions on the DCIM > Device Object Types and the API Token is set to Write Enabled the access works as expected.

user@host:~$ curl -H 'Authorization: Token <YOURTOKEN>' https://netbox/api/dcim/devices/<ID>/render-config/
{"error":"No config template found for this device."}

[abhi1693]

I would consider this as an FR rather than a bug.

[jiuka]

I would consider it a bug, as I assume the current behaviour is not the intended behaviour. In the UI a user with the view permission can view and download the renderd config. This is an inconsistency between the UI and the api.

The netbox.api.authentication.TokenPermissions requires the add permission for all POST requests and enforces the write_enabled too.

[abhi1693]

This is not inconsistent behaviour at all. When you view even in the UI, it makes a POST call.

[PhilipLoenneker]

Please note that this was raised in issue #14184 with some suggestions for ways to make the render-config API endpoint available with a read-only token.

[jiuka]

If viewed in the UI ist a GET call https://netbox/dcim/devices/<ID>/render-config/ or https://netbox/dcim/devices/<ID>/render-config/?export=True when downloaded. But this is not my point. If a login as a User with Read Only permission I can access GET https://netbox/dcim/devices/<ID>/render-config/?export=True but not POST https://netbox/api/dcim/devices/<ID>/render-config/ which both should return the same thing. This is the reason I consider this a bug and not a FR.

However to get this issue a step further towards beeing resolved, what is you final verdict on this mather and shoud new FR be created or can this issue be relabeld?

[DanSheps]

However to get this issue a step further towards beeing resolved, what is you final verdict on this mather and shoud new FR be created or can this issue be relabeld?

@jiuka this is going to be a low priority bug

[jiuka]

Would this be something I could try my hands on? My approach would be to create a TokenViewPermissions class which then could be passed to the @render decorator in the RenderConfigMixin as permission_classes.

[DanSheps]

IMO, the render config should be a get, not a post.

You aren't altering the NetBox database, you are only fetching pre-existing data.

This does require a API change and our stance is API changes must be done on non-patch releases.

[jeremystretch]

The request must be a POST to facilitate passing data in the body of the request (as opposed to query parameters) per the HTTP spec.

[DanSheps]

Are we good with @jiuka's proposal then to override the permissions?

[jeremystretch]

If a login as a User with Read Only permission I can access GET https://netbox/dcim/devices/<ID>/render-config/?export=True but not POST https://netbox/api/dcim/devices/<ID>/render-config/ which both should return the same thing. This is the reason I consider this a bug and not a FR.

There is a subtle different between these two views, however: The UI view does not accept user input whereas the REST API endpoint does.

While I agree that rendering a device configuration should not require the add_device permission, I'm going to assert that it should enforce write permission generally (i.e. by requiring a write-enabled token). The justification for this is simply that the API endpoint accepts, processes, and returns arbitrary user data for inclusion in the template context: Enforcing write ability protects against potential abuse from a malicious actor.

I've opened #16681 to introduce a new permission action specifically for rendering device & VM configurations, which I believe will address the root problem here (the inordinate requirement for "add" permission).