Skip to content

docs: clarify Python installer privilege boundary #146

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
opajonk merged 1 commit into from
Aug 17, 2026
+10 −7
Merged

docs: clarify Python installer privilege boundary #146

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 7 additions & 4 deletions tools/internal/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -89,10 +89,13 @@ Python command-line tool metadata lives in
[`tools/lockfiles/python_tools.bzl`](../lockfiles/python_tools.bzl). The file is
a data-only Starlark dictionary because Bazel must read the pin during analysis,
before the command can run. Its restricted literal form is also valid Python
syntax. The privileged DevContainer installer parses it with
`ast.literal_eval`, preserving a data-only privilege boundary. This shared
format keeps the package, console entrypoint, version, and description in one
source of truth while Bazel execution remains independent of host Python.
syntax. During DevContainer setup, `install.py` runs as root so it can install
tools in system locations such as `/usr/local/bin`. It parses the catalog with
`ast.literal_eval` instead of executing it as Python, so catalog changes can
provide only literal data and cannot run code with the installer's privileges.
This shared format keeps the package, console entrypoint, version, and
description in one source of truth while Bazel execution remains independent
of host Python.

The catalogs have distinct ownership: `devcontainer-lock.json` records external
DevContainer features, `python_tools.bzl` records Python package releases, and
Expand Down
6 changes: 3 additions & 3 deletions tools/tests/python_tool_runner_test.sh
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -52,7 +52,7 @@ chmod +x "${fake_uvx}"

# The explicit assertion verifies the requested release. Subsequent checks use
# the parsed value to keep every expected uv argument aligned with the catalog.
catalog_version="$(python3 "${installer}" version pre-commit)"
catalog_version="$("${installer}" version pre-commit)"
[[ "${catalog_version}" = "4.5.1" ]]

# The Bazel launcher receives an execroot-relative uvx path, then changes to the
Expand All @@ -75,7 +75,7 @@ assert_lines "${output}" \
# whichever home directory uv would otherwise infer during image creation.
environment_output="${TEST_TMPDIR}/uvx.env"
OUTPUT_FILE="${output}" ENV_OUTPUT="${environment_output}" \
python3 "${installer}" install-python pre-commit \
"${installer}" install-python pre-commit \
--uv "${fake_uvx}" --bin-dir /test/bin --tool-dir /test/tools

assert_lines "${output}" \
Expand All @@ -89,7 +89,7 @@ assert_lines "${environment_output}" "/test/bin" "/test/tools"
# Validate all names before invoking uv. Including a valid name first proves an
# error cannot leave behind a partially installed tool set.
rm -f "${output}"
if OUTPUT_FILE="${output}" python3 "${installer}" install-python \
if OUTPUT_FILE="${output}" "${installer}" install-python \
pre-commit missing-tool \
--uv "${fake_uvx}" 2> "${TEST_TMPDIR}/unknown.err"; then
echo "Unknown Python tool unexpectedly succeeded" >&2
Expand Down