Skip to content

Hand Teku and Nimbus data dirs to uid 1000 before start - #490

Merged
KaloyanTanev merged 2 commits into
mainfrom
kalo/vc-data-permissions
Oct 5, 2026
Merged

KaloyanTanev merged 2 commits into
mainfrom
kalo/vc-data-permissions

Conversation

@KaloyanTanev

@KaloyanTanev KaloyanTanev commented Oct 5, 2026 •

Copy link
Copy Markdown
Contributor

Teku and Nimbus images run as uid 1000, but docker creates missing bind mount directories as root, so on a fresh setup neither could write to ./data/vc-teku or ./data/vc-nimbus. Both containers now start as root only long enough for run.sh to hand the data directory to uid 1000 (chown -R 1000:1000, mode 700, which Nimbus requires). The script then re-runs itself as uid 1000 with setpriv, so key import and the client itself run unprivileged. This works whatever the host user's uid is.

Teku gets a new teku/run.sh that ends with exec /opt/teku/bin/teku "$@", and its command: is unchanged. Nimbus's run.sh is now mounted at /home/user/run.sh and set as entrypoint:, outside the data directory, so the chown doesn't change the owner of the tracked file on the host. The compose entrypoint: overrides the ENTRYPOINT of nimbus images that operators have already built.

Tested on a host user with uid 1001: the data directories were missing, root-owned, or owned by 1001 at 700, and each ended up 1000:1000 at 700. Teku's Java process and the Nimbus VC ran as uid 1000, and the scripts on the host kept their owner.

Fixes #357

@sonarqubecloud

sonarqubecloud Bot commented Oct 5, 2026

Copy link
Copy Markdown

@KaloyanTanev
KaloyanTanev merged commit d7d0c77 into main Oct 5, 2026
4 checks passed
@KaloyanTanev
KaloyanTanev deleted the kalo/vc-data-permissions branch October 5, 2026 14:02
KaloyanTanev added a commit that referenced this pull request Oct 5, 2026
`nimbus/run.sh` ran `rm -rf /home/user/data` on every start, which also
wiped the Nimbus VC's slashing protection DB
(`validators/slashing_protection.sqlite3`). It now removes only the
previously imported keys (`secrets/` and `validators/0x*`) before
re-importing them, matching charon-distributed-validator-cluster.

Before #490 the wipe mostly failed silently, because uid 1000 couldn't
write to the root-owned `./data/vc-nimbus`. Now that #490 hands that
directory to uid 1000, it succeeds on every restart.
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.

multi-client data directory permissions

2 participants