On 08/27/2014 03:15 PM, Lennart Poettering wrote:
On Wed, 27.08.14 21:00, Václav Pavlín (vpavlin@redhat.com) wrote:
I also offered to split out the hwdb in Brno, if you remember. If this is about the hwdb, then let's just do that...
Talk to Michal Sekletar about it then - he is working on "something" we call systemd-container internally. We need systemd running in Docker container. I don't like to have needless stuff in images but if the result is "just drop the hwdb" then I am fine with that.
As discussed in Brno, "not liking to have needless stuff around" alone is really not a convincing reason.
I mean, you could make the case for the size of things, but afaics this doesn't hold any water here... kmod is a 150K dep, and the other stuff, is that any bigger? For 150K we shouldn't complicate things this much...
You could also make the case for the dependencies, but this is kind the same as the size argument...
And you could make the case for "security", but that's really wrong too, since recent systemd versions have exactly zero suid binaries, and if you don't run the daemons, then you have exactly zero ways to raise your priviliges. And just having dead code lying around is not really an issue. I mean, if you managed to exploit something and smuggled in some code, then you smuggled in some code, why would make it any difference if there's dead code lying around or not in the container?
But regarding kmod/devicemapper, can we please get some stats about how big this individually are, and how much is saved by this? kmod at least is 150K or so only. Is there really any value in doing this weird stuff for a fricking 150K?! Fedora has no bigger fishes to fry?
I'll prepare stats for you tomorrow.
The systemd-container or fakesystemd stuff sounds awfully adhoc. Can we please always discuss this first, and see if we can find a different solution? We don't need three different "solutions", if one works too...
We've talked about this on Flock - it's not only about disk space but also about security reasons (CC'ing Dan Walsh). My goal was not
Dan, can you elaborate what the rationale for this is?
It is not about Security escalation is is about the need to update a container image if a CVE happens on any of the packages installed. Basically we want to keep the turn on images as small as possible. If systemd, kmod, udev ... have a CVE and they are not used within an image, then we would still need to update the image because it containers "Vulnerable" code, or potentially vulnerable code. Fakesystemd was developed for RHEL/Centos images to help minimize the CVE footprint. This was discussed on on this fpc request. https://fedorahosted.org/fpc/ticket/425. I actually did not want fakesystemd to go into Fedora for exactly the fear of it screwing up builds. I like the idea of systemd-container, or some other minimal systemd environment which understands and works well within container, and am trying to get pull requests into docker to allow systemd to work well.
https://github.com/docker/docker/pull/7685 https://github.com/docker/docker/pull/7685
If we got a good version of systemd-container, (Or systemd) which did not suck in other requirements an stopped other random rpm sucking in stuff not needed in container, I would be all for dropping fakesystemd.
to have needless junk in base image - if we are not going to use systemd to manage services there, why should it be there with all it's dependencies?
This sounds awfully like a "just because!" reason...
Lennart