-
Notifications
You must be signed in to change notification settings - Fork 137
Open
Labels
protocolProtocol Team ticketsProtocol Team tickets
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
- 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.
- Use a higher UID/GID that isn't likely associated with a local user. This would at least avoid unexpected file access being granted.
- 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
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
protocolProtocol Team ticketsProtocol Team tickets