Docker gadgetron: Must run as root?

[John Roberts]

Is it necessary for Gadgetron to be run as root?

I've been working on increasing the security on our Docker machines and attempted to run our Gadgetron docker container as a non-root user. 

As near as I can tell, one or more components requires root permission in order to run. 

Before I get lost in the weeds trying to modify the Docker to run some parts as root and others as non-root, I wanted to find out if this is even possible.  Actually, I already tried a number of variations, all of them dead ends.  I can give details about what I've tried if anyone is interested.

The only success I've had is to let root run the main components of Gadgetron, including the python and matlab portions. 

Ultimately, I'd like to limit Gadgetron to running as a non-root user before I open up the system to all my colleagues who are excited to have scripting language (matlab/python) support on the scanner.

Thanks for any information.
John.

[Xue, Hui (NIH/NHLBI) [E]]

hi John,

You can add the docker user group and set the your user to run docker without sudo:

sudo groupadd docker

sudo usermod -aG docker ID

then logout and log back in. 

you should be able to do:

docker run hello-world

without sudo.

regards

Hui Xue

---

From: John Roberts <rob...@ucair.med.utah.edu>
Sent: Thursday, May 11, 2017 6:34 PM
To: Gadgetron
Subject: Docker gadgetron: Must run as root?

 

--
You received this message because you are subscribed to the Google Groups "Gadgetron" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gadgetron+...@googlegroups.com.
To post to this group, send email to gadg...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gadgetron/cbf51f4a-7158-46db-ab63-1d755c35172b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[John Roberts]

Hi Hui,

Thanks for your response.  However, I'm not talking about how docker itself is run, but how Gadgetron runs within Docker.  I'm aware of the solution you suggest for docker group, but my question is only somewhat docker related and more about Gadgetron itself.

It seems that in the Docker implementation, Gadgetron requires root permission.

Perhaps Gadgetron itself requires root permissions even if I were to run it on the host without any Docker.

That's my question.  Does Gadgetron require root permission in order to run?

I'm wary about providing users access to scripting languages running as root.  Presumably, the c++ gadgets would also run as root.

Thanks,
John.

[John Roberts]

As near as I can tell, in the docker setup, it's the supervisor daemon that requires root permission in order to launch.  Once launched, the supervisord process can switch users (via settings in its *.conf file).

Reverse engineering the setup, I can see that it's the supervisor daemon that starts the web and jupyter services.  One or the other of those services is responsible for starting the gadgetron engine.  So, gadgetron is buried some 2 or 3 levels deep under processes that launch processes that launch Gadgetron.

At what point along the line I can switch to a non-root user and still have Gadgetron function properly is unclear.  I did manage to change the supervisor daemon settings to switch to running as a non-root user, but I immediately encountered problems with the web or jupyter services (not sure which one, the errors are cryptic). 

My best guess is that a python script some where is requesting a port for Gadgetron that is in the restricted range (<1024) requiring root permission in order to use.  But that's a wild stab in the dark on my part.

For the moment, I'm letting Gadgetron run as root, but have forced my matlab gadgets to run as non-root by inserting a change of user (using sudo) into the matlab wrapper script itself.

John.

[Michael Hansen]

Just to make it completely clear. The Gadgetron does not need root. Neither does the web_app that used to start it (written in Python) and but in the the container things run as root. The python script does not negotiate low ports or any such thing that requires root privileges. But in the container, it really doesn't matter so much. It is, running as root in a containerized environment, so unless you map you system file system in there, it is pretty well contained. 

In the mean time, we have eliminated the web_app and supervisord now starts the Gadgetron directly (https://github.com/gadgetron/gadgetron/blob/master/docker/supervisord.conf), so you can simple change the user there. Please update to a newer version. If you are not running it in a Docker container (which is probably what I would recommend if you are using Matlab), you can simply start the Gadgetron with whatever user you would like. 

Just to make it 100% clear, there is no need, whatsoever, for running the Gadgetron as root. You can run it as whatever user you would like. 

Hope this helps. 

Michael

[John Roberts]

Thanks, Michael, that was exactly the confirmation I was looking for. 

I'll either figure out how to get my container running Gadgetron as non-root, or I'll try your newest version.  Since I compile in Matlab, and compilation can take a few hours inside the container, I'll try to work with my existing version first before starting with the new Docker image.

At issue with running as root is the fact that I have to map in my matlab installation from the host for the matlab compilation inside the container.  I don't want my Gadgetron matlab users running with the power to delete the shared volume with a call from matlab running as root.  The same would apply to my python and cpp users.  I do share in other folders from the host and it's that access to the host that I need to lock down with a non-root user.

By the way, I believe my version is compiled from a Docker image only a few weeks old.  Was this a recent update, eliminating the web_app?

Thanks,
John.

[Michael Hansen]

I think the change was in this commit:

https://github.com/gadgetron/gadgetron/commit/9d47ad55d3a5fa120501930390c088bbfc9aa248

So it was March 21. 

Matlab within a container is a bit of a mess, I am afraid. It will never really be clean or safe, but of course you can make it less likely that people break stuff on accident. 

[John Roberts]

Thanks, I'll take a look.

I'd be happy to live without Matlab, but there would be cries and great gnashing of teeth on the part of my end users if I didn't support it.

Since Gadgetron is not immediately started by supervisord in the container, could you tell me which script does start Gadgetron?  I might focus my efforts there on getting it to run as non-root.

Thanks,
John.

[Michael Hansen]

In the new configuration, the Gadgetron is is immediately started by supervisord. Previously, it was started by gadgetron_web_app.py. Just do a `ps aux` in the container to the running processes, and it should be pretty obvious. 

No need to live without Matlab, but you may want to live without the convenience of a container. In the Matlab scenario, it is really more of a pain.

[John Roberts]

Yes, sorry, I forgot you mentioned that supervisord started gadgetron directly now

[John Roberts]

Taking a look at Docker hub, it seems like the

gadgetron/ubuntu_1404_cuda75

images have not been updated in 8 months, though the

ubuntu1404_cuda75_base

images have been updated in the last 2 months.  I'm not sure of the distinction.  Do the latter "base" images simply need to be compiled?  Given that I'm recompiling anyway to add in matlab support, could I start with the base image?

Actually, I see now in your build scripts on github that the non-base 1404 images will no longer be built.  I'll try the current 1604 image and see if my matlab compilation survives the Ubuntu change. 

Thanks,
John.

[John Roberts]

Success.

I was able to rebuild my Docker image with the newer Ubuntu 1604 Cuda75 image, compiling in matlab.

I was also able to modify the supervisord daemon to use the USER option to run processes under its control (ie. Gadgtron) as a specified user.  I mean the USER parameter that is entered under the supervisord section of the supervisord.conf file.

I did run into some problems initially because the supervisord.conf file shipped for Gadgetron points to a lot of locations that require root permission to read and/or write to.  Once I switched the various paths to locations my non-root user could read/write, I was able to launch the supervisord daemon which then launched Gadgetron and its child processes as the non-root user

John.