Bug: swamp extracts embedded deno into $HOME and can't exec it under SELinux Enforcing → all user extensions fail to load

Summary

On an SELinux Enforcing host, swamp extracts its embedded deno runtime to $HOME/.swamp/deno/deno. Files created under a home directory get the user_home_t SELinux type. The swamp process (running from /usr/local/bin/swamp, labeled bin_t, launched by systemd) then tries to exec that user_home_t binary as its "deno health check". The exec is denied by policy, the health check fails, swamp re-extracts (producing another user_home_t file), fails again, and finally "falls back to system deno" — which it also does not find/accept — so it loads zero user model/vault/report extensions.

Net effect: every custom extension silently stops resolving (Unknown model type: @kneel/...), which takes down any workflow, schedule, vault, or report that depends on a user extension.

The embedded deno binary itself is fine — it runs --version, eval, run, and --unstable-bundle correctly when invoked directly. The only problem is its SELinux file context after extraction.

Environment

• swamp: 20260817.010424.0-sha.21133ea1 (installed to /usr/local/bin/swamp, bin_t)
• deno (extracted): 2.8.3 (stable, release, x86_64-unknown-linux-gnu)
• OS: RHEL/Rocky 9 (el9), kernel 6.17.7-1.el9.elrepo.x86_64
• SELinux: Enforcing
• Run context: systemd unit swamp-serve.service, user swamp, `HOME=/home/[REDACTED]

Impact

• Severity: high. All user extensions fail to load on the host. Scheduled workflows that use custom model types fail at run time; CLI model method run / model type describe return Unknown model type.
• Latent until restart. A long-running swamp serve keeps the previously loaded binary mapped in memory, so it keeps working across an on-disk binary upgrade. The failure only surfaces on the next restart (or the next process that extracts fresh) — making it easy to ship a broken binary and not notice until an unrelated restart hours/days later.

Reproduction

1. Host with SELinux Enforcing; install swamp to /usr/local/bin/swamp (bin_t).
2. Run any command that needs a user extension as the service user, e.g. swamp model method run <instance> <method> where the instance's type is a local/pulled extension.
3. Observe repeated health-check failures and Unknown model type.

[WRN] swamp·runtime·deno: Extracted deno at "/home/[REDACTED]/.swamp/deno/deno" failed health check — re-extracting
[WRN] swamp·runtime·deno: Embedded deno at "/home/[REDACTED]/.swamp/deno/deno" failed health check after extraction — falling back to system deno
[WRN] swamp·cli: Failed to load user model extensions: "Embedded deno at /home/[REDACTED]/.swamp/deno/deno failed health check and no system deno found in PATH. Try: xattr -c /home/[REDACTED]/.swamp/deno/deno"
[WRN] swamp·cli: Failed to load user vault extensions: "..."
[WRN] swamp·cli: Failed to load user report extensions: "..."
Error: Unknown model type: @kneel/route-planner

Evidence it's a labeling problem, not a broken deno

$ getenforce
Enforcing

$ ls -Z /home/[REDACTED]/.swamp/deno/deno
unconfined_u:object_r:user_home_t:s0 /home/[REDACTED]/.swamp/deno/deno

$ ls -Z /usr/local/bin/swamp
unconfined_u:object_r:bin_t:s0 /usr/local/bin/swamp

# The extracted deno runs fine when invoked directly as the service user:
$ sudo -u swamp env HOME=/home/[REDACTED] /home/[REDACTED]/.swamp/deno/deno --version
deno 2.8.3 (stable, release, x86_64-unknown-linux-gnu)
$ sudo -u swamp env HOME=/home/[REDACTED] /home/[REDACTED]/.swamp/deno/deno eval 'console.log(42)'      # -> 42
$ sudo -u swamp env HOME=/home/[REDACTED] /home/[REDACTED]/.swamp/deno/deno eval --unstable-bundle 'console.log(42)'  # -> 42

A one-off chcon -t bin_t /home/[REDACTED]/.swamp/deno/deno makes the health check pass — but swamp re-extracts on the next failure and resets the label, so a manual relabel is not a durable fix (and shouldn't be required).

Root cause

swamp extracts a runtime it intends to execute into a location whose default SELinux type (user_home_t, inherited from $HOME) is not execable by the swamp domain on an Enforcing host. Extraction never restores an exec-appropriate context.

Why the existing fallbacks don't help

• Re-extraction reproduces the same bad label — infinite loop, then gives up.
• "Fall back to system deno" did not resolve it even with a working deno on PATH (reported "no system deno found in PATH"); a PATH-provided deno at a non-bin_t path would hit the same exec denial anyway.
• The remediation hint xattr -c is macOS quarantine-specific and misleading on Linux; it points users away from the actual (SELinux) cause.

Suggested fixes (swamp-side — this is the real fix)

1. Restore an exec-appropriate context after extraction. After writing ~/.swamp/deno/deno, run the equivalent of restorecon/set bin_t (or extract into a directory whose default type is execable), so the runtime is execable under Enforcing SELinux without host intervention.
2. Don't clobber a healthy runtime. Health-check the existing extracted deno before re-extracting; skip extraction when it already passes. (This also lets an operator pin a correctly-labeled deno.)
3. Support an operator-provided deno. Honor an env var / config (e.g. SWAMP_DENO_PATH) pointing at an external deno at a trusted (bin_t) path, and use it without extraction. Enables a clean host-managed runtime.
4. Fail loud, not silent. When no usable deno is found, surface a clear, actionable error instead of degrading to "zero user extensions loaded" with only WRN lines — a scheduled deployment can look healthy while loading nothing.
5. Make the hint OS-aware. Replace the xattr -c hint on Linux with an SELinux-context hint (or detect getenforce/ls -Z).

Workaround (interim, if a host-side stopgap is unavoidable)

Relabel the extracted deno to bin_t and prevent re-extraction from resetting it (e.g. by pinning a correctly-labeled deno and relying on fix #2), or provide a bin_t-labeled deno via fix #3. A bare chcon/restorecon alone is not durable because swamp re-extracts on the next failed check.