Docker for beginners and WEB UI
walters at verbum.org
Fri Mar 6 13:15:30 UTC 2015
On Fri, Mar 6, 2015, at 05:03 AM, Bohuslav Kabrda wrote:
> 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.)
There's no easy answer. Historically, most *local* daemons have been using DBus and PolicyKit for authorization. Docker is HTTP-based, which means it's easier to remote, but on the other hand, there's no way to do system-local authorization in HTTP.
Possibly we could create a shim process which had a PolicyKit-authorized DBus API that returned a file descriptor to the Docker socket. That would require patching apps that use it, but it would be more fully under admin control.
BTW, with respect to mock - now that mockchain is added, a user in the mock group can run arbitrary code as uid 0 locally - just put it in the %post of the build dependency. Modern mock uses systemd-nspawn which is more secure, but uid 0 in containers should currently be treated as uid 0 outside.
More information about the env-and-stacks