floki
floki copied to clipboard
Metaswitch
Add privileged option
--privileged is the only Docker switch currently needed by our build process in floki. With the recent change to require the "local" option if Docker switches are used it would be useful if that could be an option instead.
Seems pretty reasonable. The dind container runs with privileged, and I think in general this should be fine for reproducibility. I'll have a quick look over the docker Docs to see if to entails anything interesting, and probably knock it together in the next few days.
Just for my interest, and if you can disclose, what kind of thing do you need the privileged flag for?
Thanks! We need it to be able to manage loopback devices so the "virtualize" tool can run.
Just taking a look into this at the moment. I'm trying to understand what's really needed here. In general floki tries to avoid anything which makes the container environment reflect the host (without explicit checks, like with ssh-agent sockets) to help guarantee that the container environment is as consistent and host independent as possible. The privileged flag basically makes /dev host dependent.
Secondly, I've built some images before using loopback devices in a container (not for Metaswitch products - I think I was building my own mini-linux image by hand, as one does), and using privileged containers means your loopback setups persist over container lifetime (essentially escape the sandbox). This is also kind of a usability pain.
I think I want to figure out how to do this, but I'm not convinced that priviliged is the way to go. I think the next step is to figure out if it's possible to get loopback devices working in a full container (perhaps mknod can do this?), and if that's not possible, what minimal set of permissions are needed. Loopback devices are also a little annoying because, IIRC, they need a kernel module which most systems don't have activated by default. Containers sit on top of the kernel of course, so this isn't something that's namespaced as such (I think). Probably we need a nice usable way to feed that information back to the user.
More broadly, whats the general case here? I'm not sure loopback specific function is the way to go, but if we can figure out the right way to capture it generically, with a suitable reproducibility story, I can add that as the happy path feature.
Interested in your thoughts!
I just stumbled about this and don't understand all implications, so please excuse me if I am totally wrong.
If the loopback device setup needs somehow mount, than capability --cap-add=SYS_ADMIN would be enough instead of --privileged. However, this capability is powerful and can be abused in a container.
If the loopback device setup rather needs networking capabilities, one of NET_ADMIN or NET_BROADCAST might help.
Compare: https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities
@mviereck thanks - yeah, I think the precise permissions need to be understood.
This refers to mounting of loopback block devices (/dev/loop0 etc) from the host device. Essentially the game here is providing enough that the device is easy to access and use, yet at the same time not making too many assumptions about the host (floki is a build tool, and it's mainline use case is to be run after a git clone to get a build environment - it ought not to be tied to details of the host).
Loopback devices are fun because they need a kernel module that isn't loaded by default. In general, I probably need to think about how to solve these kinds of problems.
