biding to port < 1024 such as 443 need root permission
docker is always run by root so no issue
Dockerfile: adduser -D -u 10001 myprojectuser (in-image account, name exists only inside)
USER 10001 (default if compose says nothing)
compose: user: "${gID:-10001}:${uID:-10001}" (OVERRIDES the image's USER -> myprojectuser)
kernel: checks NUMBERS ONLY against mounted-file owners — no names cross the boundary
| Scenario | Container runs as | Host logs/ written by | joey's access |
|---|---|---|---|
.env has gID/uID = joey's ids | 700198504 (myprojectuser ignored) | joey | full — owner |
.env unset → fallback 10001 | 10001 (myprojectuser ) | nameless 10001 | read only (644/755) — can't create/delete/chown |
Two wording refinements to your summary
"mapped" isn't quite the mechanism — there's no mapping table. When the container (10001) writes to the mount, the number 10001 lands in the host inode's owner field directly; the host just displays it namelessly because no account has it. Nothing is translated in either direction.
"myprojectuser is ignored" is about the account, not the permissions — when you set joeyids, the image's
USER 10001and the myprojectuser passwd entry are bypassed entirely, but the files in the image still work for joey because wechmod -R a+rX /appin the Dockerfile (world-readable). That chmod is why any uid can run the app; theuser:line only decides whose numbers touch the mounts.
So the practical rule you've derived is exactly right: pick the number in .env, and make the mounted dirs owned by that same number — either naturally (you own them, set your ids) or once (chown 10001:10001 logs), and cleanup for the nameless case is docker run --rm -v ./logs:/w alpine chown ... since any daemon user has root on mounts.
No comments:
Post a Comment