analytics
analytics copied to clipboard
Hardcoded docker user causes problems
Past Issues Searched
- [X] I have searched open and closed issues to make sure that the bug has not yet been reported
Issue is a Bug Report
- [X] This is a bug report and not a feature request, nor asking for self-hosted support
Describe the bug
When running the docker image, the user is hardcoded to uid 1000 and the files are owned by that user. This has some issues:
- it most likely collides with the first user of the host, which is a potential security problem
- files being deployed as executable specifically for that user cannot be run by others (resulting in 0744
/app/.../elixirnot being runnable with a different uid) - some files like
/app/lib/tzdata-1.0.5/priv/latest_remote_poll.txtare expected to be written to, but that breaks with other uids
Expected behavior
Be able to run the official docker container with uid different than 1000
Screenshots
No response
Environment
- OS:
- Browser:
- Browser Version:
Agree that this should be fixed. More reading: https://sysdig.com/blog/dockerfile-best-practices/#1
Should the UID be hardcoded to a different value other than 1000 or dynamically assigned at runtime?
Ideally, it should be possible to use any uid people want.
Here's the Dockerfile that mix phx.gen.release --docker generates. I wonder if we could use something similar for the user setup.
WORKDIR "/app"
RUN chown nobody /app
# set runner ENV
ENV MIX_ENV="prod"
# Only copy the final release from the build stage
COPY --from=builder --chown=nobody:root /app/_build/${MIX_ENV}/rel/app ./
USER nobody
I remember there was some discussion about not using nobody as the user, maybe it was https://github.com/phoenixframework/phoenix/issues/4188 (PR: https://github.com/phoenixframework/phoenix/pull/4257 with lots of comments), but phx.gen.release --docker still generates it with nobody so I don't know. The author of that PR doesn't seem to know why the changes have been reverted either:
- https://github.com/phoenixframework/phoenix/commit/3763055af9c20c7dab37b18fa6abd57255574a19#r69886519
- https://github.com/phoenixframework/phoenix/commit/3763055af9c20c7dab37b18fa6abd57255574a19#r69887570
Here's how I personally define the user, but I use it in fly.io and uids are not as important there.
I wonder if that would be good enough for Plausible as well?
RUN chown nobody:nobody /app
USER nobody:nobody
COPY --from=build --chown=nobody:nobody /app/_build/prod/rel/plausible ./
👋 @viraptor Sorry for taking too long to get back.
I would like to clarify a few points.
For the first issue, even if the UID matches, the container's process is isolated with different access rights from a host process with UID 1000. And Plausible doesn't write to (bind-)mounted volumes so that mitigates potential conflicts with host user's UID on written files.
Regarding the executables, I'm trying to understand the scenario where a user other than plausibleuser would need to run them inside the container. Could you elaborate?
Lastly, files like /app/lib/tzdata-1.0.5/priv/latest_remote_poll.txt are exclusively used by Plausible. Can you explain the issue that arises with other UIDs?
Thanks!
Maybe we can do it like in ClickHouse: fixed UID but some directories are Xrw by all.
And in the article linked by Uku they suggest dropping chown-ing /app to plausibleuser and instead just allowing executables to plausibleuser. ~~I'll try that out.~~ PR: https://github.com/plausible/analytics/pull/2986 -- I think this would solve the current problem.
Unfortunately I moved to another project instead, so can't really provide more info here, sorry.
@viraptor Thank you nonetheless!
Just in case, https://github.com/plausible/analytics/pull/2986 probably resolves the issues you were having as with these changes plausible/analytics container can run as any uid:gid.