Skip to content

fix(postinst): chmod 600 the container env file#217

Merged
mairas merged 2 commits into
mainfrom
fix/env-file-permissions-600
Jun 15, 2026
Merged

fix(postinst): chmod 600 the container env file#217
mairas merged 2 commits into
mainfrom
fix/env-file-permissions-600

Conversation

@mairas

@mairas mairas commented Jun 15, 2026

Copy link
Copy Markdown
Contributor

Motivation

Container env files at /etc/container-apps/<package>/env were created world-readable (644). They can hold secrets such as INFLUXDB_ADMIN_TOKEN, so any local process could read them without root.

Approach

templates/debian/postinst.j2: add an unconditional chmod 600 on the env file immediately after the create-if-missing block, outside the first-install guard. Because postinst configure runs on every upgrade, this both restricts fresh installs and corrects already-deployed world-readable files on upgrade.

Tests

New tests/test_env_permissions.py renders the postinst and asserts the chmod 600 is present and sits after the first-install guard's fi (locking in the upgrade-hardening intent). Confirmed failing before the change, passing after.

Verification

  • Unit: 578 passed, 1 skipped
  • Integration: 27 passed
  • ruff check, ruff format --check, ty check: pass

Note

VERSION/debian/changelog intentionally not bumped here — version-cycle coordination across the parallel container-packaging-tools PRs is handled at merge time, so version-bump-check may show red until then.

Closes #201

The env file at /etc/container-apps/<package>/env can hold user-set
secrets (e.g. INFLUXDB_ADMIN_TOKEN) and the sibling env.defaults carries
shipped default credentials, but both were created world-readable (644),
letting any local process read them. Set mode 600 unconditionally so
fresh installs are restricted and existing world-readable installs are
hardened on upgrade. env.defaults is rewritten from the template on every
configure, so it is re-hardened each time.

Closes #201

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@mairas

mairas commented Jun 15, 2026

Copy link
Copy Markdown
Contributor Author

Independent security review

Reviewed the env-permission hardening with a fresh-context security persona. The chmod 600 on env is correct and well-positioned (runs on both fresh install and every upgrade, outside the first-install guard, before any reader). One real gap and two pre-existing notes:

P1 (fixed in this PR — 1bac0f7): env.defaults was left world-readable. The sibling env.defaults is generated from default_config (which for InfluxDB holds INFLUXDB_ADMIN_PASSWORD / INFLUXDB_ADMIN_TOKEN), installed 644, and rewritten unconditionally on every configure — same secret-bearing class as env, but not covered by the original fix. The chmod 600 now covers both files, and test_env_defaults_chmod_600 asserts it. Full unit suite: 878 passed.

P2 (deferred → halos-marine-containers#184): influxdb prestart create-from-absent branch. If env is absent when the InfluxDB prestart runs, it creates the file at 644 with the rotated real token. Low likelihood (postinst always creates env first), different repo / writer, so tracked separately rather than scope-creeping this PR.

P3 (deferred → #218): create-restricted idiom. The OIDC client secret (and the env/env.defaults cp) follow create-644-then-chmod rather than install -m 600 create-restricted. Root-only same-process window, pre-existing — filed as a hardening issue.

Note: CI version-bump-check is red by design — the version-cycle bump for the parallel c-p-t PRs is coordinated at merge.

@mairas mairas merged commit 7b29df7 into main Jun 15, 2026
4 checks passed
@mairas mairas deleted the fix/env-file-permissions-600 branch June 15, 2026 21:55
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Container env files are world-readable (644) — should be 600

1 participant