Docker processes running as non-root? Any way to specify user?

docker

(Brendan) #1

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.


(Kane York) #2

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.


(Kane York) #3

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:

$ find / -perm -u+s -type f
/usr/lib/pt_chown
/usr/lib/openssh/ssh-keysign
/usr/lib/eject/dmcrypt-get-device
/usr/bin/newgrp
/usr/bin/passwd
/usr/bin/fping6
/usr/bin/fping
/usr/bin/gpasswd
/usr/bin/sudo
/usr/bin/chfn
/usr/bin/chsh
/bin/umount
/bin/ping6
/bin/ping
/bin/su
/bin/mount

(Compare to my system):

Expand
/bin/umount
/bin/ping6
/bin/ping
/bin/mount
/bin/su
/bin/fusermount
/usr/lib/eject/dmcrypt-get-device
/usr/lib/openssh/ssh-keysign
/usr/lib/virtualbox/VirtualBox
/usr/lib/virtualbox/VBoxHeadless
/usr/lib/virtualbox/VBoxNetAdpCtl
/usr/lib/virtualbox/VBoxSDL
/usr/lib/virtualbox/VBoxNetDHCP
/usr/lib/policykit-1/polkit-agent-helper-1
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/lib/vmware/bin/vmware-vmx-stats
/usr/lib/vmware/bin/vmware-vmx-debug
/usr/lib/vmware/bin/vmware-vmx
/usr/lib/pt_chown
/usr/sbin/pppd
/usr/sbin/vmware-authd
/usr/bin/mtr
/usr/bin/gpasswd
/usr/bin/chsh
/usr/bin/sudo
/usr/bin/X
/usr/bin/passwd
/usr/bin/pkexec
/usr/bin/newgrp
/usr/bin/vmware-mount
/usr/bin/chfn

Keep in mind: It’s not perfect, it’s security.


(Brendan) #4

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.

Thanks @riking


(Eric Toombs) #5

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?


(Sam Saffron) #6

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.


(Eric Toombs) #7

Does that mean the user outside the container who happens to correspond has no control over the processes inside the container?

Also about the dedicated docker UID range: good idea, if it’s not too inconvenient.


(Sam Saffron) #8

Yes completely, strongly recommend you have a read about cgroups. cgroups - Wikipedia

The UID range is reasonable easy to build but I am highly concerned about backwards compat, its a change we will get to, but will take a while.


(system) #9

(Sam Saffron) #10