Problem
After #234, `HOME` on the seid container points at `dataDir` (`/sei` today). Cosmos SDK / seid subcommands that consult `~/.foo` will now write into the data PVC instead of failing with ENOENT/EACCES. Examples:
- `~/.bash_history` if anyone `kubectl exec`s with a shell
- `~/.cache/` from any Go binary using `os.UserCacheDir()`
- Cosmos SDK keyring backends defaulting to `~/.seid/keyring-*` (mediated by sidecar today, but a future image with debug entrypoints could trigger)
Surfaced during cross-review of #234 by the security-specialist agent.
Impact
The snapshot uploader (in the sidecar, `seictl serve`) is the load-bearing question. If it tars `/sei` wholesale, any dotfile that ends up under dataDir rides along into S3 and into every node that restores from that snapshot. This is "silently-introduced persistence surface" — no exploit today, but expands threat surface and creates a confused-deputy risk for future seid plugins.
Relevant experts
- security-specialist (threat model)
- platform-engineer (snapshot pipeline ownership)
Proposed approach
Two layers:
-
Audit the sidecar's snapshot upload code path. Find what subdirectory of `dataDir` is tar'd. If it's a specific subdir (e.g., `data/`), this issue is informational only — close after documenting. If it's wholesale `dataDir` content, add explicit excludes.
-
Add a defensive comment block in `internal/noderesource/noderesource.go` near the HOME env declaration, calling out that `dataDir` now resembles a home directory and any future tooling that tars or syncs from there should be explicit about what's included.
-
(Cut-first) Default excludes in the uploader: `.bash_history`, `.cache/`, `.ssh/`, `.aws/`, `.kube/`, `.config/`, `keyring-*`. Only relevant if step 1 shows wholesale-tar behavior.
Acceptance criteria
Out of scope
- Migrating dataDir to a structure that more cleanly separates "home dir" from "data dir" (would be a much larger refactor; the convention everywhere is `~/.sei == dataDir`)
- Cosmos SDK keyring relocation
References
Problem
After #234, `HOME` on the seid container points at `dataDir` (`/sei` today). Cosmos SDK / seid subcommands that consult `~/.foo` will now write into the data PVC instead of failing with ENOENT/EACCES. Examples:
Surfaced during cross-review of #234 by the security-specialist agent.
Impact
The snapshot uploader (in the sidecar, `seictl serve`) is the load-bearing question. If it tars `/sei` wholesale, any dotfile that ends up under dataDir rides along into S3 and into every node that restores from that snapshot. This is "silently-introduced persistence surface" — no exploit today, but expands threat surface and creates a confused-deputy risk for future seid plugins.
Relevant experts
Proposed approach
Two layers:
Audit the sidecar's snapshot upload code path. Find what subdirectory of `dataDir` is tar'd. If it's a specific subdir (e.g., `data/`), this issue is informational only — close after documenting. If it's wholesale `dataDir` content, add explicit excludes.
Add a defensive comment block in `internal/noderesource/noderesource.go` near the HOME env declaration, calling out that `dataDir` now resembles a home directory and any future tooling that tars or syncs from there should be explicit about what's included.
(Cut-first) Default excludes in the uploader: `.bash_history`, `.cache/`, `.ssh/`, `.aws/`, `.kube/`, `.config/`, `keyring-*`. Only relevant if step 1 shows wholesale-tar behavior.
Acceptance criteria
Out of scope
References