Hmm, looks like my email didn't make it into the list. Probably for the better, that was sent from a mobile device and probably had typos. *re* posting this from web. ---
What process is going to start this user container?
systemd in my specific case, but i presume that the same question would exist w/ any process supervisor system.
Is this any more secure then just running as root with the --promethious user?
I still don't understand your question? I am **trying** to run as the prometheus user. Up until now, i had been configuring systemd to launch invoke the `podman run ...` command **as** the host/prometheus user with a `User=prom` directive in the `.service` file. However, i had **not** been using the `--user=root` option on the container. By forcing the container image to run as `root` rather than whatever the `USER` directive in the Dockerfile was, completely sidesteps the need for subuids and managing their access to files on the host. As seen here: ## # Ignore the 777 perms on the dir, the *important* part is the uid/gid map to the host/prom user ## ``` root@com:/tmp/prom/data# ls -lah total 16K drwxrwxrwx 3 prom prom 4.0K Jan 29 00:23 . drwxrwxrwx 3 prom prom 4.0K Jan 28 19:20 .. -rw-r--r-- 1 prom prom 0 Jan 29 00:23 lock -rw-r--r-- 1 prom prom 20K Jan 29 00:23 queries.active drwxr-xr-x 2 prom prom 4.0K Jan 29 00:23 wal ``` ## # Note that the host/prom user is invoking the `podman run` command... my original goal! ## prom@com:/home/karl$ podman run --user=root -p 9090:9090 -v /tmp/prom:/etc/prometheus -v /tmp/prom/data:/prometheus prom/prometheus <snip> level=info ts=2020-01-29T00:23:11.027Z caller=main.go:617 msg="Server is ready to receive web requests." ``` to recap: - System level users are fine for rootless containers, provided that they do have a home dir for container image storage. - There is no simple way to determine precisely which UID will "own" the host files that are mapped into a container. It is possible to do so after the container has been run once. For a variety of reasons, this method should be avoided! - The simple solution is to make the sub g/uid range irrelevant by supplying the `--user-=root` flag to the `podman run` command, effectively making the "owner" of all the files mapped into the container equal to the UID of the host/user that invoked `podman run` plus an offset of 0. - Supplying the `--user=root` flag is not necessary if the container image is built without a `USER` directive... but a professionally done pre-made container image without the `USER` directive is unlikely as Docker's published best practices suggest running the process in the container under an explicit non-root UID.