feat: add clean environment option to Shell

[ntorga]

Problem

When using tkInfra.NewShell with the Username field to run commands as a different user, the parent process's environment leaks into the child process. This happens because prepareExec() inherits the parent env via execCmd.Environ() (line 140 of shell.go):

execCmd.Env = append(execCmd.Environ(), "DEBIAN_FRONTEND=noninteractive")
execCmd.Env = slices.Concat(execCmd.Env, shell.runtimeSettings.Envs)

When the parent runs as root (HOME=/root) and we pass HOME=/home/username in Envs, both entries exist in the env slice. Since getenv() returns the first match, the parent's HOME=/root takes precedence — the appended value is never seen.

This breaks rootless podman (and likely other user-scoped tools) because they resolve config paths from HOME:

faccessat /root/.config/containers/storage.conf: permission denied

Proposed Solution

Add a ShouldUseCleanEnv boolean to ShellSettings. When set to true, skip the execCmd.Environ() inheritance and build execCmd.Env solely from ShellSettings.Envs (plus the automatic DEBIAN_FRONTEND=noninteractive):

if shell.runtimeSettings.ShouldUseCleanEnv {
    execCmd.Env = []string{"DEBIAN_FRONTEND=noninteractive"}
} else {
    execCmd.Env = append(execCmd.Environ(), "DEBIAN_FRONTEND=noninteractive")
}
execCmd.Env = slices.Concat(execCmd.Env, shell.runtimeSettings.Envs)

This is backward-compatible — the default (false) preserves the current behavior.

Context

Discovered while migrating EZ's RunCmdAsUser to use tkInfra.NewShell. The function runs commands as a different system user and needs a clean environment with explicit HOME, XDG_RUNTIME_DIR, DBUS_SESSION_BUS_ADDRESS, etc. Without a clean-env option, we can't use tk Shell for this use case.

[ntorga]

@coderabbitai I don't know if I can call you here, but wouldn't it make more sense to clear the Env when Username is passed always? I mean, why would you need to inherit the parent env if you're running as a specific username?

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Fetch issue details
gh issue view 21 --repo goinfinite/tk --comments

# Search for relevant code related to Username and Env handling
rg -n "Username" --type go -C 5

Length of output: 18982

---

🏁 Script executed:

#!/bin/bash
# Get the full shell.go file to understand Env handling
cat src/infra/shell.go

Length of output: 4958

---

@ntorga, yes, you can absolutely call me here, and your suggestion is spot-on! 🎯

Looking at src/infra/shell.go (around Line 148):

execCmd.Env = append(execCmd.Environ(), "DEBIAN_FRONTEND=noninteractive")
execCmd.Env = slices.Concat(execCmd.Env, shell.runtimeSettings.Envs)

execCmd.Environ() inherits the full parent process environment regardless of whether Username is set. When running as a specific user, this means a subprocess running as (say) an unprivileged Unix user still silently inherits all env vars from the parent process, which could be running as root — leaking sensitive variables like API tokens, secret keys, or other credentials.

The fix is clean and minimal: use a fresh environment when Username is provided, keeping only the explicit Envs passed in ShellSettings plus the always-needed DEBIAN_FRONTEND=noninteractive:

if shell.runtimeSettings.Username != "" {
    execCmd.Env = []string{"DEBIAN_FRONTEND=noninteractive"}
} else {
    execCmd.Env = append(execCmd.Environ(), "DEBIAN_FRONTEND=noninteractive")
}
execCmd.Env = slices.Concat(execCmd.Env, shell.runtimeSettings.Envs)

This mirrors the behaviour of su - or sudo -i — starting with a clean environment when switching users — which is the expected and secure default. Any env vars the caller explicitly needs to pass through to the target user can still be provided via ShellSettings.Envs.

Would you like me to open a GitHub issue to track this, or go ahead and plan the code change?