This has probably been hashed over a thousand times, but I’ve got some confusion over the user that processes run as in containers (and how that shows on the host).
I’ve read this great article that explains why a process will show as running as different users, depending on if you’re viewing the process list inside the container vs. on the host, and it makes sense why it happens.
An example is the best. I’ve got an Ubuntu 16.04 box (running on EC2) and I’m pulling in and running redis in a container…specifically the 3.2.11-alpine image. It’s working great, including a mounted volume for persistence.
The Dockerfile for that image creates a “redis” user and group in the container. When I look at the process list on the host, redis-server shows as running as user “systemd-timesync”, which has a UID of 100 in /etc/passwd. This makes sense, as the redis user that’s been created in the container has an UID of 100.
Now, the confusion for me is around security and other potential issues that may arise with having the redis-server process running as the “systemd-timesync” user. Is there a security concern here, having a container process run as a different privileged user on the host? I thought specifying the -u <user> parameter on the command-line would allow me to specify the actual user (on the host) I wanted it to run as, but it ends up that that’s not the case. -u means specifying a container user, not a host user.
If someone could shed a bit of light on that, that’s be awesome.
Users have numeric IDs. The numeric ID 0 is special and can do things like ignore filesystem permissions. Otherwise, the numbers are just numbers, traditionally anything between 0 and 32767 is allowed, the important questions are “is one of the uids zero” and “are these two uids equal”.
There is (usually) a file /etc/passwd that provides a mapping between numeric user IDs and user names. But, the host and each Docker container have separate isolated filesystems, so a given user name in one context is completely meaningless in another.
In traditionalist Unix speak, only user ID 0 (root) is “privileged”. I think this only has implications to the extent that you’ve allowed processes in the container to see the filesystem and other things on the host: processes in the container can’t see random host processes and so can’t kill(2) them, regardless of uids; processes in the container can only see parts of the host filesystem via docker run -v options; and so on.
(I think it is fairly common, among standard images that have gone to the trouble of not running as root, to run as uid 1000, because that’s the default behavior you’ll get from an adduser command. Also there’s a high probability your host unprivileged uid is 1000, for the same reason.)
Nope, you’ve got it. If you want to be unambiguous, give a numeric uid to -u.
I think I’ve got it. Really, the fact that I can see that process running on the host is just a side effect…it’s not running directly on the host, but in the container only, and hence only has access to the container and any potential mount points defined therein.