So, if I start Discourse (and thus docker) via sudo /var/discourse/launcher start <config> all the docker processes run as the user who ran sudo… let’s say for example that user is bob, UID=1000.
If I do top -u bob, I see all of the discourse processes (unicorn, sidekiq, etc)
Is there any way to change this behavior? bob isn’t the semantically correct user for all the discourse processes to be running as, regardless of the fact that I technically launched discourse as that user. Is the only alternative running the launcher from the root user directly? or can I specify a user from the launcher script to run these processes as?
As far as I understand docker, it’s supposed to be running as root, which is why the processes running under bob surprised me.
They’re actually running as a namespaced UID. The processes inside the container see UID 1000, but it’s actually a different UID 1000 from the host filesystem.
The actual starting command is run as sudo -E -u discourse bla bla bla, and discourse in the container gets the first “free” user UID, which is 1000.
Note: This is useful because if someone somehow gets a command execution vulnerability in Discourse, they won’t be able to see much about the host system - or even make changes that survive a rebuild without somehow getting the database to trigger command execution.
They won’t be able to compromise the host without a root elevation.
Here’s a list of the SUID executables inside the container:
Got it, so I’m just seeing bob because it’s running under uid 1000 inside the container. That makes sense. Given my unfamiliarity with the underpinnings of docker, I just wasn’t sure what was going on.
Though running as non-root is obviously a good idea, I find the choice of user (very) odd. Usually, a user dedicated to the daemon is run. For example, the user opendkim runs opendkim. This ensures the regular user bob does not have control over anything it doesn’t need to, or perhaps shouldn’t.
Also, I don’t get how discourse decided to pick my username in the first place. The only thing I can come up with is it assumes everybody will start the daemon using sudo (A dubious assumption) and checks the environment variable $SUDO_USER.
The only other explanation I can come up with is that UID=1000 has a different meaning within the docker container. Does this mean UID=1000 doesn’t have access (eg. ability to send UNIX signals) to the docker processes, even though the process UID is right?
I think you are getting tripped by the fact that UIDs in the container live in a world unto themselves.
The user running Discoruse is “discourse” but since this discourse user does not exist at all on the host, on the host the UID will map to the user on the host with the same UID.
To circumvent this weird we could possibly dedicate a range of UIDs in both host and image and have launcher take care of creating parity.