Closes #22654: Redact install paths from debug tracebacks

[bctiemann]

Closes: #22654

Summary

• ConfigTemplate.format_render_error() now strips the absolute install-path prefix from all File "..." lines in the Jinja2 traceback before returning it, so internal filesystem layout is not disclosed to users (CWE-209).

Root cause

ConfigTemplate.format_render_error() returned traceback.format_exception(exc) verbatim when debug=True. The output includes File "/abs/install/path/..." entries for every Python frame in the traceback, revealing the absolute filesystem layout of the NetBox installation to whoever can trigger a render error (CWE-209).

Fix

Path redaction — after calling traceback.format_exception(), apply re.sub with a pattern anchored to re.escape(install_root) (computed as os.path.dirname(settings.BASE_DIR) + os.sep) to replace the absolute prefix with an empty string. The result is a traceback with paths relative to the repo root, which is safe to show. When the venv lives outside the repo, its root is stripped separately as well.

Tests

Added test_format_render_error_debug_redacts_install_path and test_format_render_error_non_debug_returns_concise_message to ConfigTemplateDebugTestCase in extras/tests/test_models.py. Existing test_render_jinja2_* and ConfigTemplateTestCase tests continue to pass.

[bctiemann]

@claude /review and report only on areas of potential concern.

[github-actions]

Claude finished @bctiemann's task in 3m 43s —— View job

---

PR Review: Redact install paths from debug tracebacks; restrict debug field to superusers

Tasks:

• Understand request (code review, report only concerns)
• Read changed files
• Analyze implementation for security, correctness, and design issues
• Post findings

---

Areas of Potential Concern

1. Incomplete Path Redaction — Venv and Stdlib Paths Remain Visible

extras/models/configs.py:332

install_root = os.path.dirname(settings.BASE_DIR) + os.sep

The regex strips only paths under install_root (the parent of BASE_DIR). Traceback frames from two common sources are left verbatim:

• Python stdlib — e.g. File "/usr/lib/python3.12/abc.py" — reveals the OS Python path, which is low-risk but still information disclosure.
• Virtualenv outside the repo — e.g. File "/home/deploy/.venv/netbox/lib/python3.12/site-packages/jinja2/..." — this reveals the deployment user's home directory path (e.g. /home/deploy/) and is deployment-specific. This is the common deployment pattern for NetBox (the docs and AGENTS.md both use ~/.venv/netbox).

The comment in the code says venv paths are "under install_root (including the venv)", but a venv at ~/.venv/netbox is outside install_root. The claim in the comment is only correct when the venv happens to be inside the repo directory. In the typical case, the venv path disclosure is only partially mitigated.

Fix this →

---

2. self.form Mutation Is Fragile

extras/views.py:1225-1231

def get(self, request, *args, **kwargs):
    self.form = functools.partial(forms.ConfigTemplateForm, request=request)
    return super().get(request, *args, **kwargs)

def post(self, request, *args, **kwargs):
    self.form = functools.partial(forms.ConfigTemplateForm, request=request)
    return super().post(request, *args, **kwargs)

The pattern overwrites the class-level attribute form = forms.ConfigTemplateForm with an instance variable. This works because Django instantiates a new view object per request, so there's no race condition. However:

• The class attribute form = forms.ConfigTemplateForm (line 1223) remains as a silent fallback — if either get() or post() is bypassed (e.g. a dispatch() override in a mixin or subclass), the un-partial'd form class is used, silently dropping the superuser gate.
• The more idiomatic Django CBV approach would be to override get_form_class() (if the base view supports it) or implement a get_form() override, making it impossible to call the base view logic without the guard being applied.

This is not a bug in the current code but is a maintenance risk if the class hierarchy changes.

---

3. API Test Gap: Non-superuser Setting debug=False Is Not Covered

extras/tests/test_api.py:1287-1307

There's a test that a non-superuser setting debug=True returns 400, and a test that a superuser setting debug=True returns 200. Missing from coverage:

• Non-superuser PATCHing debug=False should succeed (permitted). There's no test for this path.
• Non-superuser PATCHing other fields on a template that already has debug=True in the DB should preserve debug=True (i.e., validate_debug should not fire when debug is absent from the payload). This is also untested.

These are the "allow" paths for non-superusers and are worth explicitly testing to guard against regressions in validate_debug.

---

4. Fieldset Filter Has a Known Blind Spot — Comment Should Be Stronger

extras/forms/model_forms.py:863-864

# Note: the fieldset filter is a top-level string scan; InlineFields/TabbedGroups wrappers
# around 'debug' would not be caught, but none exist in the current fieldset definition.

This is correctly documented, but the code's correctness now depends on a non-obvious constraint ("none exist in the current fieldset definition"). If a future contributor wraps the debug field in an InlineFields or TabbedGroups, the field will silently reappear for non-superusers in the fieldset rendering while still being absent from self.fields. This would cause a template rendering error rather than a security bypass (the field is deleted from self.fields before the fieldset renders), but it's a fragility worth noting.

---

Summary: The core security intent (redact install paths; gate debug writes to superusers) is sound. The main practical gap is #1 — venv paths outside install_root can still disclose the deployment user's home directory when debug tracebacks are shown. Items #2–#4 are code-quality and test-coverage observations rather than vulnerabilities.

[bctiemann]

Addressed items 1 and 3. 2 and 4 are minor/below the bar for this fix.

[jeremystretch]

The debug field is now restricted to superusers

This cannot be included in the scope of a bug fix, as it represents a change to intended functionality. It needs to be a separate FR. Please revert the related changes so that the PR is limited to the sanitization of file paths.

[bctiemann]

Much simpler change now. Also opened #22664 to track the superuser gate.