Tuesday, 1 September 2026

Privelege port and docker user creation and permission

 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
ScenarioContainer runs asHost logs/ written byjoey's access
.env has gID/uID = joey's ids700198504 (myprojectuser ignored)joeyfull — owner
.env unset → fallback 1000110001 (myprojectuser )nameless 10001read only (644/755) — can't create/delete/chown

Two wording refinements to your summary

  1. "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.

  2. "myprojectuser is ignored" is about the account, not the permissions — when you set joeyids, the image's USER 10001 and the myprojectuser passwd entry are bypassed entirely, but the files in the image still work for joey because we chmod -R a+rX /app in the Dockerfile (world-readable). That chmod is why any uid can run the app; the user: 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