Repository navigation
Script run responses include storage backend error text #88
Description
Plugin Version
v0.0.1 (also present on main)
NetBox Version
v4.7.4
Python Version
3.12
Steps to Reproduce
- Use the default filesystem storage backend for script source.
- Activate a revision for an upload project so it has a runnable Script.
- Make that revision's stored files unreadable by the NetBox process, and clear the local runtime cache so the run has to read from storage.
- Run the Script through the REST API (
POST /api/plugins/scripts/scripts/<id>/run/), or from its run view in the UI.
Expected Behavior
The response says the Script could not be loaded, without storage backend details. The full error goes to the server log for the administrator.
Observed Behavior
Found by reading the code on main, not by running these steps. The example message below shows the shape the code produces, not captured output.
The load failure is shown to the user by api/views.py:351-358 (REST) and views/scripts.py:198 (UI). It comes from script_class_context, which passes the error through build_error_sanitizer (validation.py:239-261). The sanitizer replaces the storage key, digest, local cache directory and runtime root, but not the storage backend's own root path or other backend text. Reading a stored file wraps the backend exception text (storage/store.py, _stream_verified), so a filesystem read failure still shows something like Permission denied: '/opt/netbox/netbox/media/<scripts root>/<storage>/<digest>/script.py'. Other backends would include their own error text, such as an S3 endpoint URL.
The upload path has the same root cause and is covered by #77. CodeQL reports this one as py/stack-trace-exposure (alert 3).
Activity
[-]Storage backend error text reaches upload and script run responses[/-][+]Script run responses include storage backend error text[/+]jnovinger commentedon Oct 29, 2026
I narrowed this to the script run path, since #77 already covers the upload path (including the
ImproperlyConfiguredhandler). The run path differs because its errors pass throughbuild_error_sanitizer, which strips the storage key and digest but leaves the storage backend's root path and any other backend text. Both cases come fromStorageErrorwrapping the backend exception text, so a single fix there could close both. @pheus, feel free to fold this into #77 if that's easier.jnovinger commentedon Oct 29, 2026
Update: #71 fixed the REST run path (it now logs the error and returns a generic message), so alert 3 is closed. What remains here is the UI run view, which still includes the raw error at
netbox_scripts/views/scripts.py:202.