On 08/27/2014 03:15 PM, Lennart Poettering wrote: > On Wed, 27.08.14 21:00, Václav Pavlín (vpavlin@xxxxxxxxxx) 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 > -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
