ObolNetwork / ObolNetwork/charon

Charon container runs as user 1000

Open
#4,326 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

protocol
Dominant language
Go
Stars
222
Forks
138
Avg merge
2d 6h
Merged PRs (30d)
35

Description

🎯 Problem to be solved

The charon docker container runs with user=1000 specified in the Dockerfile, so all consumed artifacts must be owned by this user (ENR, cluster lock etc). This is usually fine if the cluster admin is user 1000, but if they aren't then permission issues can arise:

  • When the cluster admin generates artifacts outside the charon container (via cli etc), the files will have the wrong permissions and the charon container will be unable to start without changing file permissions first, which is confusing since you'd then need to figure out what user charon is running as.
  • When artifacts are created by the charon container, they will be owned by user 1000 and be unreadable by the cluster admin without elevating privileges. This also gives another user (1000) on the system access to the cluster artifacts which is likely not intended.

Potential Solutions

  1. Let charon run as root, which would be in-line with the other containers that already run as root (VC). This would eliminate the issue with artifacts owned by the "wrong" user from stopping the charon container from starting. Created artifacts would still be inaccessible without elevated privileges.
  2. Use a higher UID/GID that isn't likely associated with a local user. This would at least avoid unexpected file access being granted.
  3. Start container as root, chown target directory to uid/gid 1000, then drop privileges.

🧪 Tests

  • Files created by a UID other than 1000 can be read by the Charon container

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing the user=1000 setting in the Dockerfile and the artifact-permission test described in the issue. Compare the three listed startup and UID approaches with the existing container behavior; done means the agreed approach is implemented and files created by a UID other than 1000 are readable by Charon.

Written by the indexing model from the issue text.

Assessment

Tech stack
docker
Domain
infrastructure
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.