You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It currently runs as root, which is bad for a couple reasons:
Possible security / escalation concerns
Files we write to local disk (like if you point the output or PHI folders at a local dir) have root ownership.
Problems that prevent us from trivially fixing this:
USER in a Dockerfile means we use a hardcoded UID/GID for inside the container - which may not match outside the container, and may prevent us from writing files to a local folder owned by someone else.
--user ${id -u}:{id -g} on the console is awkward and not something we currently provide a script for to automate away.
User namespaces / UID remapping is a docker daemon-side feature, not a container feature.
Solutions:
Wrapper script for docker compose run that provides --user?
Or at least document --user as an option for the security-conscience in our user docs
Use an entrypoint script that starts as root, then downgrades permissions to the same user that owns the output folder, if local. The caller would have to trust us there and it feels brittle. But an option.
Something else?
The text was updated successfully, but these errors were encountered:
It currently runs as root, which is bad for a couple reasons:
Problems that prevent us from trivially fixing this:
USER
in a Dockerfile means we use a hardcoded UID/GID for inside the container - which may not match outside the container, and may prevent us from writing files to a local folder owned by someone else.--user ${id -u}:{id -g}
on the console is awkward and not something we currently provide a script for to automate away.Solutions:
--user
?--user
as an option for the security-conscience in our user docsThe text was updated successfully, but these errors were encountered: