On Sun, 19.07.15 22:38, Paul Menzel ([email protected]) wrote:
> 1. The capability `SYS_ADMIN` has to be given(?) to the Docker > container. > > --cap-add SYS_ADMIN systemd should work OK now even if you don't pass the cap. That said, this takes away the effect of things like PrivateNetwork=, PrivateDevices=, PrivateTmp= and other namespace-related things from the containers, as well as a few other things. Hence I'd not recommend doing that, the kernel isn't really ready for this... > So a container with that capability won’t be that contained anymore. Currently, containers on Linux are not a security technology. Don't mistake them for that. Without --private-users there are more holes in them than in swiss cheese. And even if you do use that, it's still no security technology, yet. > 2. systemd-docker [4][7] > > Quoting the systemd-docker README.md [4]: > > > Why I wrote this? > > > > The full context is in Docker Issue #6791 [5] and this mailing list > > thread [6]. The short of it is that systemd does not actually > > supervise the Docker container but instead the Docker client. This > > makes systemd incapable of reliably managing Docker containers > > without hitting a bunch of really odd situations. > > Is it planned to solve this in systemd somehow or is it a Docker issue > from systemd’s standpoint? THis is something to fix in Docker. rkt handles this much nicer btw. > 3. There must also have been some “container improvements” between > systemd 215 and 221. At least I think, that running systemd 215 in the > container with Debian Jessie/stable it starts unnecessary(?) processes > like systemd-udev, while that doesn’t happen when Debian > Stretch/testing with systemd 221 [8] is used. `systemctl status` and > `ps aux` just show the journal and the configured programs like Cron > and Rsyslog. > > Is that just equivalent of deleting the “wants targets”, Dan talked > about in his blog post [1][2], or some big code changes? Would that be > easily “backportable” to systemd 215? We have adjusted systemd all the time. Especially to make it work in CAP_SYS_ADMIN-less and userns containers. But please don't ask me which fix we made when, that'd be a lot of work to figure out. I can only direct you towards the git history for that. > 4. Current developments > > Is there an overview of the latest developments in this regard, like > logging and other things? So many things are created and developed, > that I might have missed something. > > Like some parser of Docker Compose configuration files creating systemd > unit files from it? I am not invovled with Docker, I cannot really answer these questions. > Or should Docker be avoided anyway, because systemd-nspawn or something > similar does something similar in a much easier fashion? Well Docker solves a different problem set, such as orchestration over multiple machines in a cluster, it has build tools and whatnot. nspawn is just a container executor, with a focus on reusing existing standards, and good intgeration of the rest of the OS. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
