From 8f8be20885b4cd200a2b4a82939c94e343e2bd1f Mon Sep 17 00:00:00 2001 From: Rongsong Shen Date: Mon, 12 Oct 2026 10:12:15 +0000 Subject: [PATCH] docs(spec): application-profile: clean env for the outer pre/post-exec, reserved XCE_ prefix Co-Authored-By: Claude Opus 5.5 (1M context) --- .kiro/specs/application-profile/brief.md | 26 +++++++++++++++++++++--- 1 file changed, 23 insertions(+), 3 deletions(-) diff --git a/.kiro/specs/application-profile/brief.md b/.kiro/specs/application-profile/brief.md index d8682c58..5a62def8 100644 --- a/.kiro/specs/application-profile/brief.md +++ b/.kiro/specs/application-profile/brief.md @@ -339,6 +339,27 @@ How each profile attribute combines with the job's own value (owned by whose resreq sets terms is rejected until PR-15 named parts define per-part merging (leaning; requirements decide). +### Environment of the outer layer and reserved names +Decided 2026-10-12 (user), replacing the idea of an env denylist: +- **A. The profile's pre/post-exec runs in a clean environment**: system + values (`XCE_*`, `HOME`, a fixed `PATH`) plus the profile's own env, never + the job's. The job's env applies after it, to the job's pre-exec, the job + and the job's post-exec. An admin script that needs job facts reads + `XCE_*`. Today the job env is applied first (`apply_env_vars()`, + `worker/src/xcecd_worker.c:835`, then `queue_pre_exec()` :843), so a job's + `PATH` or `BASH_ENV` can subvert the admin's script. Worker change in this + spec: the outer layer gets an explicitly built env (`uv_proc_pre_exec` + takes none today). It also fixes today's queue pre/post-exec. +- **B. The `XCE_` prefix is reserved**: neither a job nor a profile may set + `XCE_*` variables (rejected at submit by apiserver and controller, and by + `xceadmin` for profiles). +- Why no denylist: the whole job unit runs as the execution user + (`User=` on the transient unit, `worker/src/xcecd_cgroups.c:299-312`), in + sandbox mode inside the sandbox, so `LD_PRELOAD` and similar are not an + escalation; the real risks were the admin's outer layer and XCE's own + variables, which A and B close at the source. Sandbox-specific env + exposure stays with `job-sandbox-execution`. + ### Presets (client side, `xcecli-presets`) Not part of this spec, recorded here because they replace profile defaults: - A preset is a set of job options (`--app`, `--queue`, `-R`, `-n`, env, @@ -500,14 +521,13 @@ with the reason "application profile X is not defined". - `jobmod --app` for a pending job: who may, and the bulk form (leaning: the owner with `app:use` on the new profile; admins in bulk). - Raised 2026-10-12, not yet decided: - - A denylist of env variables a sandbox profile forbids jobs to add - (e.g. `LD_PRELOAD`)? - Job labels (`--label key=value`, e.g. the preset name) and a summary grouped by label, to compare tuning variants: here, `job-status-detail-display`, or `xcecli-presets`? - Settled 2026-10-12: scheduling and execution values frozen at dispatch, re-read on requeue ("Dispatch record"); a removed profile - makes its jobs pend ("Profile removed while jobs use it"); override granularity (no markers; additive rule), + makes its jobs pend ("Profile removed while jobs use it"); clean env for + the outer layer and reserved `XCE_` instead of an env denylist; override granularity (no markers; additive rule), limits a job may lower (profile limits are maximums), personal presets (client side), `app:override` and inheritance (deferred). - Splitting the spec: execution mode, I/O directories, capability