Docker for beginners and WEB UI

Nick Coghlan ncoghlan at gmail.com
Fri Mar 6 11:46:34 UTC 2015


On 6 March 2015 at 20:03, Bohuslav Kabrda <bkabrda at redhat.com> wrote:
> ----- Original Message -----
>> On Thu, Mar 5, 2015, at 05:35 AM, Tomas Tomecek wrote:
>> >
>> > Put yourself in docker group, why would you run docker client as root?
>>
>> https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2015-January/msg00034.html
>
> Interesting, thanks for sharing.
> This makes me wonder how DevAssistant should approach this. Up until now, DevAssistant just added the invoking user to the "docker" group and then communicated with docker using docker-py library. Now, if we're not supposed to add the user to "docker" group, we can't use the library, because all the calls will fail - or we'd need to ask user to run DevAssistant as root, which is IMO wrong.
> AFAIK there's no way to elevate DevAssistant permissions temporarily just to do the docker call. So what is the recommended approach to do this? (This is a general problem, I think, for code that needs to communicate with local Docker server.)

I believe you should be able to use sudo for this, at least in
principle. We do that in Beaker's provisioning system to give system's
under test the ability to synchronously delete their own netboot files
without giving them any other access to the TFTP root directories.
Specifically, we drop this file into sudoers.d to give the apache
process access to a trusted command we wrote specifically to handle
that task: https://git.beaker-project.org/cgit/beaker/tree/LabController/sudoers.d/beaker_proxy_clear_netboot

It seems to me that DevAssistant should be able to provide a similar
script that it runs with elevated privileges, so only that script
needs to be checked for being safe to run as a member of the docker
group.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the env-and-stacks mailing list