Mismatching User/Group cause file permission issues on Unix

[boukeversteegh]

Description

Files created by dockerized commands are not owned by the host's current user, but for example root. This makes dockerized hard to use on unix systems, as generated files cannot be modified by the user.

It is also inconsistent with the design goal that Dockerized commands should behave the same as native commands.

Reproduction

> dockerized bash -c 'touch foo'
ls -l foo
-rw-r--r-- 1 root root 0 Apr 22 10:57 foo

Possible Solutions

These are all ideas I could come up with so far. Your thoughts and suggestions are welcome. The goal is to find a solution with no blockers (:x:), and remove ❔ by doing more research.

• Run the docker image with the uid/gid of the host system
  • ❔ Ensure container images still work
  • :x: The host's user id will not exist in the container. This leads to several problems:
    • Container files owned by root (which is the default on most images) may become inaccessible, e.g. /root
    • The user will not have a username
    • The user will not have a home directory (~ will point to /)
  • ❔ Create a user inside the docker container with the host uid/gid, upon start (i.e. with an entrypoint)
    • ❔ Might clash if the specific container already uses that user-id.
  • ❔ Create a dockerfile for each app, that creates a host user, baked into the image
    • ❔ How to ensure this works for multiple host users? E.g. if the host switches to user2, dockerized should still work, and create files as user2.
• ❔ Map host ids to container ids
  • userns-remap
  • Requires re-configuring docker, and is global.
    • ❔ Will this impact the user's other containers? If so, this is not a great option.
  • ID translation
  • ❔ Does this exist somehow? Docker doesn't seem to allow ad-hoc uid translation.
  • Resources
  • https://linuxnatives.net/2019/align-user-ids-inside-and-outside-docker-with-subuser-mapping
  • https://echorand.me/posts/docker-user-namespacing-remap-system-user/
• ❔ ID translation at the filesystem level
  • ❔ Change mounting settings so that id's are immediately mapped by docker
  • ❔ Re-mount the working directory within Unix, and somehow do id translation there, then mount that directory into docker
  • https://github.com/hanwen/go-fuse/
• ❔ ID translation within the container
  • Somehow wrap the executed command and translate id's at the user level
  • :x: This is pretty much the same as running the container with --user, causing permission problems, e.g. reading /root
  • Somehow remount the mounted host directory within the container, somehow translating the ids
  • https://www.joyfulbikeshedding.com/blog/2021-03-15-docker-and-the-host-filesystem-owner-matching-problem.html
  • ❔ how
• ✔/:x: Changing the owners/permissions of the generated files after each command is run
  • :x: This won't work for long running commands, such as npm run which continuously updates files. Permissions won't be fixed until the program finishes.
  • Detecting which files need permission fixes:
  • :x: Cannot use file stats, as some commands output files with specific mtimes (e.g. tar)
  • :x: Cannot rely on just detecting new files, as some files may have been re-created with different owners
  • ✔️ Remembering all files + permissions before the command, and detecting new files and files with different owners/permissions.
    • ❔☹ Performance. Although filesystem access can be insanely fast: For example https://github.com/boyter/scc
  • ❔ Another way to detect generated / changed files?
  • Implementation: Let Dockerized fix the permissions
  • :x: requires running dockerized as root
  • ✔️ Implementation: Let docker fix the permissions. I.e. run dockerized alpine chown $(id -u):$(id -g) $FILES (this works)
  • ☹ Performance (running another container adds 450ms, on my local virtual ubuntu)
  • If docker can generate the files as root on the host system, it can also run chmod on those files
  • If docker cannot generate files as root, then the problem didn't occur either, although the files may be owner by docker or another user.
  • Implementation: Run chown within the container, after the user's command. E.g. with an entrypoint script.
  • ❔ Do all unix containers have chown?
  • 😄 Performance will be better (no extra container overhead)
  • Can combine the two approaches (within container if possible, otherwise in separate container)