We want to stop systemd from being added to docker images, because of rpm requiring systemctl.
The problem is lots of services require systemd because they ship a unit file and want systemctl reload to happen. Systemd then triggers a require for udev and kmod, which docker containers do not need.
rpm -q --whatrequires systemd| wc -l 151
On rawhide I see 151 packages on my system which require systemd.
We have a couple of options we could add a package called fakesystemd which provides a /usr/bin/systemctl that does nothing and does a provides systemd in the specfile. Then if the user wanted to install systemd into a container it would need to obsolete the fakesystemd package.
Or we could break out /usr/bin/systemctl into its own package and have it be smart enough to do nothing if systemd did not exist.
On 28 April 2014 15:01, Daniel J Walsh dwalsh@redhat.com wrote:
The problem is lots of services require systemd because they ship a unit file and want systemctl reload to happen. Systemd then triggers a require for udev and kmod, which docker containers do not need.
rpm -q --whatrequires systemd| wc -l 151
On rawhide I see 151 packages on my system which require systemd.
We have a couple of options we could add a package called fakesystemd which provides a /usr/bin/systemctl that does nothing and does a provides systemd in the specfile. Then if the user wanted to install systemd into a container it would need to obsolete the fakesystemd package.
Or we could break out /usr/bin/systemctl into its own package and have it be smart enough to do nothing if systemd did not exist.
Option 3 (not sure which is the best long term): Can the systemd files be broken out into seperate subpackages and that is just general practice?
Though I think a container-systemd (eg fakesystemd) might work better long term because if there turns out to be a useful talking mechanism needed between the containers and the real systemd it could be done via that packages eventual contents.
On Apr 28, 2014 5:01 PM, "Daniel J Walsh" dwalsh@redhat.com wrote:
The problem is lots of services require systemd because they ship a unit file and want systemctl reload to happen.
Would removing the requires on systemd and doing:
/usr/bin/systemctl reload ||:
Work for these cases?
-Toshio
On Mon, Apr 28, 2014 at 03:11:07PM -0700, Toshio Kuratomi wrote:
On Apr 28, 2014 5:01 PM, "Daniel J Walsh" dwalsh@redhat.com wrote:
The problem is lots of services require systemd because they ship a unit file and want systemctl reload to happen.
Would removing the requires on systemd and doing:
/usr/bin/systemctl reload ||:
Work for these cases?
It should. I like this option the best.
(Splitting out subpackages is a lot of work, generates overhead of thousands of trivial packages, and most importantly, is confusing for the user.
Options like manually installing fakesystemd or rpm-e-systemd-ing after installation seems are hacks that quickly get annoying, especially that you need to repeat them after upgrades.)
Zbyszek
Le 29/04/2014 00:11, Toshio Kuratomi a écrit :
On Apr 28, 2014 5:01 PM, "Daniel J Walsh" <dwalsh@redhat.com mailto:dwalsh@redhat.com> wrote:
The problem is lots of services require systemd because they ship a unit file and want systemctl reload to happen.
Would removing the requires on systemd and doing:
/usr/bin/systemctl reload ||:
Work for these cases?
-Toshio
+1
Besides, systemd should be installed in all systems where it'd make sense.
Regards, H.
On Mon, 28.04.14 15:11, Toshio Kuratomi (a.badger@gmail.com) wrote:
On Apr 28, 2014 5:01 PM, "Daniel J Walsh" dwalsh@redhat.com wrote:
The problem is lots of services require systemd because they ship a unit file and want systemctl reload to happen.
Would removing the requires on systemd and doing:
/usr/bin/systemctl reload ||:
Work for these cases?
Note that all the invocations of systemctl done by the systemd rpm macros are suffixed with ">/dev/null 2>&1 || :", as it is customary for rpm scriplets. Hence there's little to do really, except dropping the deps, and leaving everything else in place...
Lennart
On 04/29/2014 06:31 AM, Lennart Poettering wrote:
On Mon, 28.04.14 15:11, Toshio Kuratomi (a.badger@gmail.com) wrote:
On Apr 28, 2014 5:01 PM, "Daniel J Walsh" dwalsh@redhat.com wrote:
The problem is lots of services require systemd because they ship a unit file and want systemctl reload to happen.
Would removing the requires on systemd and doing:
/usr/bin/systemctl reload ||:
Work for these cases?
Note that all the invocations of systemctl done by the systemd rpm macros are suffixed with ">/dev/null 2>&1 || :", as it is customary for rpm scriplets. Hence there's little to do really, except dropping the deps, and leaving everything else in place...
Lennart
That seems ideal.
On 04/29/2014 12:31 PM, Lennart Poettering wrote:
On Mon, 28.04.14 15:11, Toshio Kuratomi (a.badger@gmail.com) wrote:
On Apr 28, 2014 5:01 PM, "Daniel J Walsh" dwalsh@redhat.com wrote:
The problem is lots of services require systemd because they ship a unit file and want systemctl reload to happen.
Would removing the requires on systemd and doing:
/usr/bin/systemctl reload ||:
Work for these cases?
Note that all the invocations of systemctl done by the systemd rpm macros are suffixed with ">/dev/null 2>&1 || :", as it is customary for rpm scriplets. Hence there's little to do really, except dropping the deps, and leaving everything else in place...
I suspect just dropping the deps would break initial installations, e.g. anaconda / livecd-creator. RPM uses the deps to order the transaction so that systemd gets installed first, and the packages that ship service files get installed later. Without the deps, rpm wouldn't know the order in which it has to run the transaction.
For example, when a package bar has a postinstall script that does:
systemctl enable bar.service >/dev/null 2>&1 || :
... but if systemctl gets installed _after_ foo in the same transaction, then the systemctl command never runs and service stays disabled.
On 04/30/2014 10:05 AM, Kalev Lember wrote:
On 04/29/2014 12:31 PM, Lennart Poettering wrote:
On Mon, 28.04.14 15:11, Toshio Kuratomi (a.badger@gmail.com) wrote:
On Apr 28, 2014 5:01 PM, "Daniel J Walsh" dwalsh@redhat.com wrote:
The problem is lots of services require systemd because they ship a unit file and want systemctl reload to happen.
Would removing the requires on systemd and doing:
/usr/bin/systemctl reload ||:
Work for these cases?
Note that all the invocations of systemctl done by the systemd rpm macros are suffixed with ">/dev/null 2>&1 || :", as it is customary for rpm scriplets. Hence there's little to do really, except dropping the deps, and leaving everything else in place...
I suspect just dropping the deps would break initial installations, e.g. anaconda / livecd-creator. RPM uses the deps to order the transaction so that systemd gets installed first, and the packages that ship service files get installed later. Without the deps, rpm wouldn't know the order in which it has to run the transaction.
For example, when a package bar has a postinstall script that does:
systemctl enable bar.service >/dev/null 2>&1 || :.. but if systemctl gets installed _after_ foo in the same transaction, then the systemctl command never runs and service stays disabled.
Well you are never supposed to do this. You are only supposed to do a systemctl reload bar in a post install. Any package that does do an enable, should require systemd, as they are probably not candidates to run in a container.
On 04/30/2014 04:24 PM, Daniel J Walsh wrote:
On 04/30/2014 10:05 AM, Kalev Lember wrote:
For example, when a package bar has a postinstall script that does:
systemctl enable bar.service >/dev/null 2>&1 || :.. but if systemctl gets installed _after_ foo in the same transaction, then the systemctl command never runs and service stays disabled.
Well you are never supposed to do this. You are only supposed to do a systemctl reload bar in a post install.
No, pretty much all packages that install systemd unit files run either 'systemctl enable' or 'systemd preset' in %post. The latter is just 'systemd enable' wrapped in layer of indirection, that depending on installed configuration either enables or disables the unit file.
The macro that systemd ships for postinstall and packages are supposed to run, is %systemd_post. That expands to a 'systemctl enable' equivalent:
$ rpm -E %systemd_post
if [ $1 -eq 1 ] ; then # Initial installation /usr/bin/systemctl preset >/dev/null 2>&1 || : fi
Any package that does do an enable, should require systemd, as they are probably not candidates to run in a container.
Right. And enable ~= %systemd_post, which is why packages that use this macro currently have Requires(post) on systemd.
On Wed, Apr 30, 2014 at 16:05:37 +0200, Kalev Lember kalevlember@gmail.com wrote:
I suspect just dropping the deps would break initial installations, e.g. anaconda / livecd-creator. RPM uses the deps to order the transaction so that systemd gets installed first, and the packages that ship service files get installed later. Without the deps, rpm wouldn't know the order in which it has to run the transaction.
For example, when a package bar has a postinstall script that does:
systemctl enable bar.service >/dev/null 2>&1 || :
... but if systemctl gets installed _after_ foo in the same transaction, then the systemctl command never runs and service stays disabled.
Couldn't that be done post transaction, instead of post install?
When this is figured out, it would be nice to see the correct pattern be documented somewhere in the packing pages, similar to the documentation for icon cache updating (https://fedoraproject.org/wiki/Packaging:ScriptletSnippets?rd=Packaging/Scri...).
On Wed, 2014-04-30 at 16:05 +0200, Kalev Lember wrote:
I suspect just dropping the deps would break initial installations, e.g. anaconda / livecd-creator. RPM uses the deps to order the transaction so that systemd gets installed first, and the packages that ship service files get installed later. Without the deps, rpm wouldn't know the order in which it has to run the transaction.
For example, when a package bar has a postinstall script that does:
systemctl enable bar.service >/dev/null 2>&1 || :... but if systemctl gets installed _after_ foo in the same transaction, then the systemctl command never runs and service stays disabled.
If you are right, this is an argument for rpm collections, which we've had for ages now and should really start using.
- ajax
On 04/30/2014 10:28 AM, Adam Jackson wrote:
On Wed, 2014-04-30 at 16:05 +0200, Kalev Lember wrote:
I suspect just dropping the deps would break initial installations, e.g. anaconda / livecd-creator. RPM uses the deps to order the transaction so that systemd gets installed first, and the packages that ship service files get installed later. Without the deps, rpm wouldn't know the order in which it has to run the transaction.
For example, when a package bar has a postinstall script that does:
systemctl enable bar.service >/dev/null 2>&1 || :... but if systemctl gets installed _after_ foo in the same transaction, then the systemctl command never runs and service stays disabled.
If you are right, this is an argument for rpm collections, which we've had for ages now and should really start using.
- ajax
Created a ticket.
https://fedorahosted.org/fpc/ticket/425
Next I will create a change request if the ticket is approved.
On Wed, 30.04.14 10:42, Daniel J Walsh (dwalsh@redhat.com) wrote:
On 04/30/2014 10:28 AM, Adam Jackson wrote:
On Wed, 2014-04-30 at 16:05 +0200, Kalev Lember wrote:
I suspect just dropping the deps would break initial installations, e.g. anaconda / livecd-creator. RPM uses the deps to order the transaction so that systemd gets installed first, and the packages that ship service files get installed later. Without the deps, rpm wouldn't know the order in which it has to run the transaction.
For example, when a package bar has a postinstall script that does:
systemctl enable bar.service >/dev/null 2>&1 || :... but if systemctl gets installed _after_ foo in the same transaction, then the systemctl command never runs and service stays disabled.
If you are right, this is an argument for rpm collections, which we've had for ages now and should really start using.
- ajax
Created a ticket.
https://fedorahosted.org/fpc/ticket/425
Next I will create a change request if the ticket is approved.
Note that just dropping systemd from your images might not be the best choice, as you then have no owners for a lot of drop-in dirs, which made be bad for verifying the software installed in the container images...
Lennart
On Fri, May 02, 2014 at 12:41:51PM +0200, Lennart Poettering wrote:
Created a ticket. https://fedorahosted.org/fpc/ticket/425 Next I will create a change request if the ticket is approved.
Note that just dropping systemd from your images might not be the best choice, as you then have no owners for a lot of drop-in dirs, which made be bad for verifying the software installed in the container images...
Yeah, I was just talking about that with some people. Maybe those dirs should be moved to 'filesystem'?
Dne 2.5.2014 15:10, Matthew Miller napsal(a):
On Fri, May 02, 2014 at 12:41:51PM +0200, Lennart Poettering wrote:
Created a ticket. https://fedorahosted.org/fpc/ticket/425 Next I will create a change request if the ticket is approved.
Note that just dropping systemd from your images might not be the best choice, as you then have no owners for a lot of drop-in dirs, which made be bad for verifying the software installed in the container images...
Yeah, I was just talking about that with some people. Maybe those dirs should be moved to 'filesystem'?
I hope that you are speaking about 'systemd-filesystem' not 'filesystem'. 'filesystem' package should not be dumping ground.
I am asking, since this reminds me issues with SCLs and ownership of filesystem(s) [1].
Vít
On Fri, May 02, 2014 at 03:50:36PM +0200, Vít Ondruch wrote:
Note that just dropping systemd from your images might not be the best choice, as you then have no owners for a lot of drop-in dirs, which made be bad for verifying the software installed in the container images...
Yeah, I was just talking about that with some people. Maybe those dirs should be moved to 'filesystem'?
I hope that you are speaking about 'systemd-filesystem' not 'filesystem'. 'filesystem' package should not be dumping ground.
It already kind of is a dumping ground. :)
I think it comes down to how common the requirement is. Since the directories in question are used by a huge number of packages it might make sense to put them in the general package rather than making a new subpackage.
But I don't really have a strong preference either way.
Dne 2.5.2014 16:29, Matthew Miller napsal(a):
On Fri, May 02, 2014 at 03:50:36PM +0200, Vít Ondruch wrote:
Note that just dropping systemd from your images might not be the best choice, as you then have no owners for a lot of drop-in dirs, which made be bad for verifying the software installed in the container images...
Yeah, I was just talking about that with some people. Maybe those dirs should be moved to 'filesystem'?
I hope that you are speaking about 'systemd-filesystem' not 'filesystem'. 'filesystem' package should not be dumping ground.
It already kind of is a dumping ground. :)
Unfortunately I have to agree on this point, but please do not use it as an excuse. Rather, It should be cleaned up.
I think it comes down to how common the requirement is. Since the directories in question are used by a huge number of packages it might make sense to put them in the general package rather than making a new subpackage.
May be we should deploy some RPM generator, which would generated dependencies on -filesystem subpackages, if their amount should be of concern.
Also, it would be beauty, if RPM could use these -filesystem packages during build of packages (just dreaming :).
Vít
On 04/30/2014 04:28 PM, Adam Jackson wrote:
If you are right, this is an argument for rpm collections, which we've had for ages now and should really start using.
YES!
Getting rid of the copy-pasted rpm scriptlets would be a huge win. They are error prone and require huge effort to get them right and up to date across the whole distro.
dpkg has had support for triggers for quite some time and the rpm world is really lagging behind here.
https://wiki.debian.org/DpkgTriggers
On 04/30/2014 02:52 PM, Kalev Lember wrote:
On 04/30/2014 04:28 PM, Adam Jackson wrote:
If you are right, this is an argument for rpm collections, which we've had for ages now and should really start using.
YES!
Getting rid of the copy-pasted rpm scriptlets would be a huge win. They are error prone and require huge effort to get them right and up to date across the whole distro.
dpkg has had support for triggers for quite some time and the rpm world is really lagging behind here.
Can packaging noobs get any doc reference on how to implement these collection and if the case is we have had them for a long time why did we never start using them?
JBG
On 30 April 2014 15:52, Kalev Lember kalevlember@gmail.com wrote:
Getting rid of the copy-pasted rpm scriptlets would be a huge win.
Totally agree. We should make this happen. SUSE has been doing it for years.
Richard
On Wed, Apr 30, 2014 at 10:28:56AM -0400, Adam Jackson wrote:
On Wed, 2014-04-30 at 16:05 +0200, Kalev Lember wrote:
I suspect just dropping the deps would break initial installations, e.g. anaconda / livecd-creator. RPM uses the deps to order the transaction so that systemd gets installed first, and the packages that ship service files get installed later. Without the deps, rpm wouldn't know the order in which it has to run the transaction.
For example, when a package bar has a postinstall script that does:
systemctl enable bar.service >/dev/null 2>&1 || :... but if systemctl gets installed _after_ foo in the same transaction, then the systemctl command never runs and service stays disabled.
If you are right, this is an argument for rpm collections, which we've had for ages now and should really start using.
What are "rpm collections" and how do they relate to "software collections"? How does this solve the package installation order without dependencies? It is hard to find anything useful by searching for "rpm collections".
On Wed, 2014-04-30 at 12:34 -0400, Chuck Anderson wrote:
On Wed, Apr 30, 2014 at 10:28:56AM -0400, Adam Jackson wrote:
On Wed, 2014-04-30 at 16:05 +0200, Kalev Lember wrote:
For example, when a package bar has a postinstall script that does:
systemctl enable bar.service >/dev/null 2>&1 || :... but if systemctl gets installed _after_ foo in the same transaction, then the systemctl command never runs and service stays disabled.
If you are right, this is an argument for rpm collections, which we've had for ages now and should really start using.
What are "rpm collections"
Scriptlets bound to a directory instead of a package's %post.
and how do they relate to "software collections"?
They don't.
How does this solve the package installation order without dependencies?
Since the collection action runs for any transaction element that affects the collection directory, you just need to pile up touch files that say to enable a service, and the action will eventually run once systemctl exists. (Roughly speaking; probably we could make it cleaner than that. Collections seem only to implement "every package" hooks atm, but for things like fonts it might be reasonable to just run the hook analogously to %posttrans rather than analogously to %post.)
It is hard to find anything useful by searching for "rpm collections".
Yeah, they're not well documented yet. Luckily I was able to track down a copy of the rpm source so I could read how it works.
The other downside is they're new in rpm 4.9, and RHEL6 only has 4.8, so there's a spec portability problem for EPEL6.
- ajax
On Wed, Apr 30, 2014 at 1:14 PM, Adam Jackson ajax@redhat.com wrote:
It is hard to find anything useful by searching for "rpm collections".
Yeah, they're not well documented yet. Luckily I was able to track down a copy of the rpm source so I could read how it works.
"In an industry wrought with broken promises and broken relationships, RPM provides a refreshing and intelligent alternative to our clients. We start by applying our intellectual capital and analytical insight to your entire receivables process..."
Oh! Different RPM collections...
On 04/30/2014 08:14 PM, Adam Jackson wrote:
On Wed, 2014-04-30 at 12:34 -0400, Chuck Anderson wrote:
On Wed, Apr 30, 2014 at 10:28:56AM -0400, Adam Jackson wrote:
On Wed, 2014-04-30 at 16:05 +0200, Kalev Lember wrote:
For example, when a package bar has a postinstall script that does:
systemctl enable bar.service >/dev/null 2>&1 || :... but if systemctl gets installed _after_ foo in the same transaction, then the systemctl command never runs and service stays disabled.
If you are right, this is an argument for rpm collections, which we've had for ages now and should really start using.
What are "rpm collections"
Scriptlets bound to a directory instead of a package's %post.
No. The thing known as "collections" in rpm source are more like named triggers. You're thinking of "file triggers" like in dpkg.
and how do they relate to "software collections"?
They don't.
How does this solve the package installation order without dependencies?
Since the collection action runs for any transaction element that affects the collection directory, you just need to pile up touch files that say to enable a service, and the action will eventually run once systemctl exists. (Roughly speaking; probably we could make it cleaner than that. Collections seem only to implement "every package" hooks atm, but for things like fonts it might be reasonable to just run the hook analogously to %posttrans rather than analogously to %post.)
It is hard to find anything useful by searching for "rpm collections".
Yeah, they're not well documented yet. Luckily I was able to track down a copy of the rpm source so I could read how it works.
Well then you've misread, and now people trying to search for information on rpm collections will be even more confused...
Like said elsewhere in this thread, collections are experimental, not enabled in Fedora and will never be in the state they currently are. So I'm not going to explain how something that does not work, works.
- Panu -
On Sat, 2014-05-03 at 10:14 +0300, Panu Matilainen wrote:
Well then you've misread, and now people trying to search for information on rpm collections will be even more confused...
Like said elsewhere in this thread, collections are experimental, not enabled in Fedora and will never be in the state they currently are. So I'm not going to explain how something that does not work, works.
I apologize for spreading misinformation.
- ajax
On 04/30/2014 05:28 PM, Adam Jackson wrote:
On Wed, 2014-04-30 at 16:05 +0200, Kalev Lember wrote:
I suspect just dropping the deps would break initial installations, e.g. anaconda / livecd-creator. RPM uses the deps to order the transaction so that systemd gets installed first, and the packages that ship service files get installed later. Without the deps, rpm wouldn't know the order in which it has to run the transaction.
For example, when a package bar has a postinstall script that does:
systemctl enable bar.service >/dev/null 2>&1 || :... but if systemctl gets installed _after_ foo in the same transaction, then the systemctl command never runs and service stays disabled.
If you are right, this is an argument for rpm collections, which we've had for ages now and should really start using.
No.
The thing called collections has never been enabled in Fedora builds because it has never gotten out of experimental state upstream, and by now its rather clear it needs to change in all sorts of ways before it could be considered non-experimental.
- Panu -
On Mon, 2014-04-28 at 17:01 -0400, Daniel J Walsh wrote:
The problem is lots of services require systemd because they ship a unit file and want systemctl reload to happen. Systemd then triggers a require for udev and kmod, which docker containers do not need.
rpm -q --whatrequires systemd| wc -l 151
On rawhide I see 151 packages on my system which require systemd.
We have a couple of options we could add a package called fakesystemd which provides a /usr/bin/systemctl that does nothing and does a provides systemd in the specfile. Then if the user wanted to install systemd into a container it would need to obsolete the fakesystemd package.
Or we could break out /usr/bin/systemctl into its own package and have it be smart enough to do nothing if systemd did not exist.
Or you could just rpm -e systemd once you've done the initial rpm install, since it's just a Requires(post) and not a permanent Requires?
- ajax
On 04/28/2014 06:44 PM, Adam Jackson wrote:
On Mon, 2014-04-28 at 17:01 -0400, Daniel J Walsh wrote:
The problem is lots of services require systemd because they ship a unit file and want systemctl reload to happen. Systemd then triggers a require for udev and kmod, which docker containers do not need.
rpm -q --whatrequires systemd| wc -l 151
On rawhide I see 151 packages on my system which require systemd.
We have a couple of options we could add a package called fakesystemd which provides a /usr/bin/systemctl that does nothing and does a provides systemd in the specfile. Then if the user wanted to install systemd into a container it would need to obsolete the fakesystemd package.
Or we could break out /usr/bin/systemctl into its own package and have it be smart enough to do nothing if systemd did not exist.
Or you could just rpm -e systemd once you've done the initial rpm install, since it's just a Requires(post) and not a permanent Requires?
- ajax
Although it would get sucked back in if a user did another yum install (Update?) that needed systemctl.
On Mon, 28.04.14 17:01, Daniel J Walsh (dwalsh@redhat.com) wrote:
The problem is lots of services require systemd because they ship a unit file and want systemctl reload to happen. Systemd then triggers a require for udev and kmod, which docker containers do not need.
If you discount the docs/man pages of the RPMs, how much does kmod, udev, systemd actually contribtue in bytes to your docker images?
Lennart
On 04/29/2014 06:33 AM, Lennart Poettering wrote:
On Mon, 28.04.14 17:01, Daniel J Walsh (dwalsh@redhat.com) wrote:
The problem is lots of services require systemd because they ship a unit file and want systemctl reload to happen. Systemd then triggers a require for udev and kmod, which docker containers do not need.
If you discount the docs/man pages of the RPMs, how much does kmod, udev, systemd actually contribtue in bytes to your docker images?
Lennart
Shrinking the the docker image is more then just size. We want to eliminate packages that are not used (Within reason) to eliminate problems like CVE's. If udev/systemd/kmod had a CVE we would need to update all Container images.
On Tue, 29.04.14 10:37, Daniel J Walsh (dwalsh@redhat.com) wrote:
On 04/29/2014 06:33 AM, Lennart Poettering wrote:
On Mon, 28.04.14 17:01, Daniel J Walsh (dwalsh@redhat.com) wrote:
The problem is lots of services require systemd because they ship a unit file and want systemctl reload to happen. Systemd then triggers a require for udev and kmod, which docker containers do not need.
If you discount the docs/man pages of the RPMs, how much does kmod, udev, systemd actually contribtue in bytes to your docker images?
Lennart
Shrinking the the docker image is more then just size. We want to eliminate packages that are not used (Within reason) to eliminate problems like CVE's. If udev/systemd/kmod had a CVE we would need to update all Container images.
Well, if you are this principled maybe. But do note that we dont really ship suid binaries (except one binary with fscaps which is systemd-detect-virt), and hence by leaving systemd in the image without running it should result in no increased attack surface that wasn't there anyway... Dead code in the image, that cannot be use to acquire new caps isn't much of a security threat...
Lennart
Em 29-04-2014 12:27, Lennart Poettering escreveu:
On Tue, 29.04.14 10:37, Daniel J Walsh (dwalsh@redhat.com) wrote:
On 04/29/2014 06:33 AM, Lennart Poettering wrote:
On Mon, 28.04.14 17:01, Daniel J Walsh (dwalsh@redhat.com) wrote:
The problem is lots of services require systemd because they ship a unit file and want systemctl reload to happen. Systemd then triggers a require for udev and kmod, which docker containers do not need.
If you discount the docs/man pages of the RPMs, how much does kmod, udev, systemd actually contribtue in bytes to your docker images?
Lennart
Shrinking the the docker image is more then just size. We want to eliminate packages that are not used (Within reason) to eliminate problems like CVE's. If udev/systemd/kmod had a CVE we would need to update all Container images.
Well, if you are this principled maybe. But do note that we dont really ship suid binaries (except one binary with fscaps which is systemd-detect-virt), and hence by leaving systemd in the image without running it should result in no increased attack surface that wasn't there anyway... Dead code in the image, that cannot be use to acquire new caps isn't much of a security threat...
You're considering only the escalation way to do it, but there are other ways to exploit code laying around, like when some web pages don't sanitize the URL enough and end up allowing executing something in the system, much like sql injection. In those cases, one could craft URLs to run wget or any other tool that may help the intruder get even more inside.
It's a pile of faults, yes, but the result isn't good and one good preventive step is keeping the dead/not needed stuff away.
Marcelo
Once upon a time, Marcelo Ricardo Leitner marcelo.leitner@gmail.com said:
You're considering only the escalation way to do it, but there are other ways to exploit code laying around, like when some web pages don't sanitize the URL enough and end up allowing executing something in the system, much like sql injection. In those cases, one could craft URLs to run wget or any other tool that may help the intruder get even more inside.
Down that path lies madness. Are you going to remove /bin/sh? If not, virtually anything else is possible.
Am 29.04.2014 20:51, schrieb Chris Adams:
Once upon a time, Marcelo Ricardo Leitner marcelo.leitner@gmail.com said:
You're considering only the escalation way to do it, but there are other ways to exploit code laying around, like when some web pages don't sanitize the URL enough and end up allowing executing something in the system, much like sql injection. In those cases, one could craft URLs to run wget or any other tool that may help the intruder get even more inside.
Down that path lies madness. Are you going to remove /bin/sh? If not, virtually anything else is possible
wrong question - is /bin/sh used? if the answer is yes then the anser to your question is no
the point is remove anything *unneeded* from production systems that are best practices for many years and for good reasons
anything which is not present can't make troubles
* security * things get enabeld by bugs * wasted space (keep backups in mind, especially off-site backups) * possible dependecy problems
on cloud-systems (to play bullshit-bingo) or simply virtualized infrastructure you pay multiple times for any overhead and if the case happens that you pay for a security problem this is also multiplied
that's why on hardened systems mostly customized packages are installed and the most interesting outputs of ./configure --help are the ones starting with "--without" and "--disable"
Once upon a time, Reindl Harald h.reindl@thelounge.net said:
wrong question - is /bin/sh used? if the answer is yes then the anser to your question is no
the point is remove anything *unneeded* from production systems that are best practices for many years and for good reasons
No, the point is that "remove a bunch of stuff to 'secure' the system" is not security, and should not be claimed that it is being done for 'security'. If you have bash as /bin/sh (as a 'standard' Fedora system does), you don't need wget/curl to download stuff for example.
Can you lock that down more? Sure, you can remove network access, remove local write access, etc. However, that is separate from removing arbitrary binaries from the system/image. Removing non-privileged binaries from the image does _nothing_ for security (as claimed up-thread).
On 04/29/2014 03:17 PM, Chris Adams wrote:
Once upon a time, Reindl Harald h.reindl@thelounge.net said:
wrong question - is /bin/sh used? if the answer is yes then the anser to your question is no
the point is remove anything *unneeded* from production systems that are best practices for many years and for good reasons
No, the point is that "remove a bunch of stuff to 'secure' the system" is not security, and should not be claimed that it is being done for 'security'. If you have bash as /bin/sh (as a 'standard' Fedora system does), you don't need wget/curl to download stuff for example.
Can you lock that down more? Sure, you can remove network access, remove local write access, etc. However, that is separate from removing arbitrary binaries from the system/image. Removing non-privileged binaries from the image does _nothing_ for security (as claimed up-thread).
I am looking at this from a tools perspective. If I run an scap tool that says container image XYZ has a vulnerable image of udev, even if udev is not being used, I will have to update the image. If it does not have the package, no reason to update.
On Tue, Apr 29, 2014 at 03:31:45PM -0400, Daniel J Walsh wrote:
On 04/29/2014 03:17 PM, Chris Adams wrote:
Once upon a time, Reindl Harald h.reindl@thelounge.net said:
wrong question - is /bin/sh used? if the answer is yes then the anser to your question is no
the point is remove anything *unneeded* from production systems that are best practices for many years and for good reasons
No, the point is that "remove a bunch of stuff to 'secure' the system" is not security, and should not be claimed that it is being done for 'security'. If you have bash as /bin/sh (as a 'standard' Fedora system does), you don't need wget/curl to download stuff for example.
Can you lock that down more? Sure, you can remove network access, remove local write access, etc. However, that is separate from removing arbitrary binaries from the system/image. Removing non-privileged binaries from the image does _nothing_ for security (as claimed up-thread).
I am looking at this from a tools perspective. If I run an scap tool that says container image XYZ has a vulnerable image of udev, even if udev is not being used, I will have to update the image. If it does not have the package, no reason to update.
Welcome to the wonderful world of containers, ignoring 20 years of shipping software in Linux distributions!
Am 29.04.2014 21:31, schrieb Daniel J Walsh:
On 04/29/2014 03:17 PM, Chris Adams wrote:
Once upon a time, Reindl Harald h.reindl@thelounge.net said:
wrong question - is /bin/sh used? if the answer is yes then the anser to your question is no
the point is remove anything *unneeded* from production systems that are best practices for many years and for good reasons
No, the point is that "remove a bunch of stuff to 'secure' the system" is not security, and should not be claimed that it is being done for 'security'. If you have bash as /bin/sh (as a 'standard' Fedora system does), you don't need wget/curl to download stuff for example.
Can you lock that down more? Sure, you can remove network access, remove local write access, etc. However, that is separate from removing arbitrary binaries from the system/image. Removing non-privileged binaries from the image does _nothing_ for security (as claimed up-thread).
I am looking at this from a tools perspective. If I run an scap tool that says container image XYZ has a vulnerable image of udev, even if udev is not being used, I will have to update the image. If it does not have the package, no reason to update
exactly *that* is the problem people never had to work the one or other way in security business not understanding
if you have external security audits there is no "can this be a problem" you finally get "fix that within 24 hours or shutdown" with no choice
been there and while 100% sure the audit result is from the category "a fool with a tool is still a fool" no choice to ignore it and god beware you manage to explain that it is not relevant followed by a real exploit two days later
Am 29.04.2014 21:17, schrieb Chris Adams:
Once upon a time, Reindl Harald h.reindl@thelounge.net said:
wrong question - is /bin/sh used? if the answer is yes then the anser to your question is no
the point is remove anything *unneeded* from production systems that are best practices for many years and for good reasons
No, the point is that "remove a bunch of stuff to 'secure' the system" is not security, and should not be claimed that it is being done for 'security'. If you have bash as /bin/sh (as a 'standard' Fedora system does), you don't need wget/curl to download stuff for example.
Can you lock that down more? Sure, you can remove network access, remove local write access, etc. However, that is separate from removing arbitrary binaries from the system/image. Removing non-privileged binaries from the image does _nothing_ for security (as claimed up-thread)
simple example:
* binary XYZ is vulerable for privilege escalation * we talk about a *local* exploit until now * a bad configured webserver allows system-commands through a php-script and i consider that you google for the /e modifier * a exploit for the web application triggers that binary * voila you have a *remote* privilege escalation to get root access
*that* is how attacks can work if things are going wrong you may now come with how likely that happens
it's not a matter of how likely, it happened in the past and it will happen in the future and every time such things happened people came with "i did not imagine that this could be possible"
so learn from the past, realize that things are possible and reduce the attack surface for the imaginary you don't believe
well, you can ignore that and still pretend "that is not security" others did that too in many cases learning it the hard way
On Tue, Apr 29, 2014 at 12:33 PM, Reindl Harald h.reindl@thelounge.net wrote:
simple example:
- binary XYZ is vulerable for privilege escalation
This makes no sense...
- we talk about a *local* exploit until now
...I don't even know what you're trying to say here...
- a bad configured webserver allows system-commands through a php-script and i consider that you google for the /e modifier
...and this is already sufficient for a remote exploit.
Can we please move all discussion of "Zomg! This feature would take an existing security hole and turn it into a security hole with exactly the same impact" into its own thread or just stop it entirely? All it does is distract from real discussion.
--Andy
Am 29.04.2014 21:36, schrieb Andrew Lutomirski:
On Tue, Apr 29, 2014 at 12:33 PM, Reindl Harald h.reindl@thelounge.net wrote:
simple example:
- binary XYZ is vulerable for privilege escalation
This makes no sense...
for you
- we talk about a *local* exploit until now
...I don't even know what you're trying to say here...
than google for
* "privilege escalation" * "local exploit" * "remote exploit"
that could be a good start: http://en.wikipedia.org/wiki/Exploit_%28computer_security%29
- a bad configured webserver allows system-commands through a php-script and i consider that you google for the /e modifier
...and this is already sufficient for a remote exploit.
yes, but the difference may be if you only can run unprivileged code or have a chance to own the machine and get root
Can we please move all discussion of "Zomg! This feature would take an existing security hole and turn it into a security hole with exactly the same impact" into its own thread or just stop it entirely? All it does is distract from real discussion
can you please start to goole for things others talking about?
On Tue, Apr 29, 2014 at 12:48 PM, Reindl Harald h.reindl@thelounge.net wrote:
Am 29.04.2014 21:36, schrieb Andrew Lutomirski:
On Tue, Apr 29, 2014 at 12:33 PM, Reindl Harald h.reindl@thelounge.net wrote:
simple example:
- binary XYZ is vulerable for privilege escalation
This makes no sense...
for you
- we talk about a *local* exploit until now
...I don't even know what you're trying to say here...
than google for
- "privilege escalation"
- "local exploit"
- "remote exploit"
that could be a good start: http://en.wikipedia.org/wiki/Exploit_%28computer_security%29
- a bad configured webserver allows system-commands through a php-script and i consider that you google for the /e modifier
...and this is already sufficient for a remote exploit.
yes, but the difference may be if you only can run unprivileged code or have a chance to own the machine and get root
Can you give an actual concrete example of wtf you're talking about? Because I suspect that you're completely wrong, but maybe you're right and no one on this thread understands what you're trying to say.
Feel free to say things like "suppose I have a php app that does XYZ" and feel free to add supposedly vulnerable udev binaries, copies of sh, copies of busybox, copies of python, gcc, etc, as needed for this to make any sense.
--Andy
Em 29-04-2014 17:04, Andrew Lutomirski escreveu:
On Tue, Apr 29, 2014 at 12:48 PM, Reindl Harald h.reindl@thelounge.net wrote:
Am 29.04.2014 21:36, schrieb Andrew Lutomirski:
On Tue, Apr 29, 2014 at 12:33 PM, Reindl Harald h.reindl@thelounge.net wrote:
simple example:
- binary XYZ is vulerable for privilege escalation
This makes no sense...
for you
- we talk about a *local* exploit until now
...I don't even know what you're trying to say here...
than google for
- "privilege escalation"
- "local exploit"
- "remote exploit"
that could be a good start: http://en.wikipedia.org/wiki/Exploit_%28computer_security%29
- a bad configured webserver allows system-commands through a php-script and i consider that you google for the /e modifier
...and this is already sufficient for a remote exploit.
yes, but the difference may be if you only can run unprivileged code or have a chance to own the machine and get root
Can you give an actual concrete example of wtf you're talking about? Because I suspect that you're completely wrong, but maybe you're right and no one on this thread understands what you're trying to say.
Feel free to say things like "suppose I have a php app that does XYZ" and feel free to add supposedly vulnerable udev binaries, copies of sh, copies of busybox, copies of python, gcc, etc, as needed for this to make any sense.
In simple terms: when you go to sleep at night, do you leave your toolbox right in front of your locked front door, ready for anyone to use it on your door? I do hope not, and that's the point in here. Or you're just too naive to believe that the street wall is just enough to hide it and nothing else is needed.
"Ohh but you remove X while program Y can also be used!" Yes, it can! But makes it harder, that's the point. Can bash open tcp sockets? Yes. Bash can pass through proxies easily? No. But wget can. "Ohh but then someone also needs the proxy information" Yes, and that's not the point here. You already have 1 obstacle more.
You have to think out of the box here, we're brainstorming on why a toolbox in your front door may or not be a liability. Security is way much more than privilege escalation. You are not considering that someone may be able to trigger an event and simply start a DoS, due to systemd or whatever in question not being properly initialized. Exposing this theoretical trigger here to you so you "understand it", right now, it out of scope. I hope you understand that.
Marcelo
On Tue, Apr 29, 2014 at 1:57 PM, Marcelo Ricardo Leitner marcelo.leitner@gmail.com wrote:
Em 29-04-2014 17:04, Andrew Lutomirski escreveu:
On Tue, Apr 29, 2014 at 12:48 PM, Reindl Harald h.reindl@thelounge.net wrote:
Am 29.04.2014 21:36, schrieb Andrew Lutomirski:
On Tue, Apr 29, 2014 at 12:33 PM, Reindl Harald h.reindl@thelounge.net wrote:
simple example:
- binary XYZ is vulerable for privilege escalation
This makes no sense...
for you
- we talk about a *local* exploit until now
...I don't even know what you're trying to say here...
than google for
- "privilege escalation"
- "local exploit"
- "remote exploit"
that could be a good start: http://en.wikipedia.org/wiki/Exploit_%28computer_security%29
- a bad configured webserver allows system-commands through a
php-script and i consider that you google for the /e modifier
...and this is already sufficient for a remote exploit.
yes, but the difference may be if you only can run unprivileged code or have a chance to own the machine and get root
Can you give an actual concrete example of wtf you're talking about? Because I suspect that you're completely wrong, but maybe you're right and no one on this thread understands what you're trying to say.
Feel free to say things like "suppose I have a php app that does XYZ" and feel free to add supposedly vulnerable udev binaries, copies of sh, copies of busybox, copies of python, gcc, etc, as needed for this to make any sense.
In simple terms: when you go to sleep at night, do you leave your toolbox right in front of your locked front door, ready for anyone to use it on your door? I do hope not, and that's the point in here. Or you're just too naive to believe that the street wall is just enough to hide it and nothing else is needed.
The bad guys have their own tools.
"Ohh but you remove X while program Y can also be used!" Yes, it can! But makes it harder, that's the point. Can bash open tcp sockets? Yes. Bash can pass through proxies easily? No. But wget can. "Ohh but then someone also needs the proxy information" Yes, and that's not the point here. You already have 1 obstacle more.
If you want to go down that path, set up selinux to prevent execing things that oughtn't to be execed. But trying to prevent exploits from working by removing every possible helper from the path is a losing proposition and is just not worth doing.
You have to think out of the box here, we're brainstorming on why a toolbox in your front door may or not be a liability. Security is way much more than privilege escalation.
You are not considering that someone may be able to trigger an event and simply start a DoS, due to systemd or whatever in question not being properly initialized. Exposing this theoretical trigger here to you so you "understand it", right now, it out of scope. I hope you understand that.
Sorry, wrong. Systemd *isn't running*, so you can't trigger an event.
--Andy
Am 29.04.2014 23:09, schrieb Andrew Lutomirski:
If you want to go down that path, set up selinux to prevent execing things that oughtn't to be execed. But trying to prevent exploits from working by removing every possible helper from the path is a losing proposition and is just not worth doing
defense in depth means you are doing *both* defense in depth means limit the attack surface as much as you can defense in depth means place security layers behind others to surive a failing one defense in depth means disable and remove anything which is not needed for your tasks
Once upon a time, Reindl Harald h.reindl@thelounge.net said:
defense in depth means limit the attack surface as much as you can
No, because "as much as you can" is turn the system off and bury it in concrete (with an armed guard).
The goal is "as much as practical". Trying to remove things that are needed is not practical.
Spending a whole bunch of effort to allow you to remove systemd (again, just the files, it isn't running) seems excessive. There are some basic things that RPMs expect; installing a service expects that the service management tools are present.
Am 29.04.2014 23:20, schrieb Chris Adams:
Once upon a time, Reindl Harald h.reindl@thelounge.net said:
defense in depth means limit the attack surface as much as you can
No, because "as much as you can" is turn the system off and bury it in concrete (with an armed guard).
The goal is "as much as practical". Trying to remove things that are needed is not practical
ok, now it is proven that you only try to quibbling
* the system needs to do a job * turn it off means pretty clear it can't do it's job * as much as you can means pretty clear not stop it's job
you can't tun it off because it's not practical
however, thank you to show me that any discussion with you is worthless because you are more interested in words than in their content and maybe be proud to be an native english speaker - congratulaitions for that but it won't help that much at the end of the day
Once upon a time, Reindl Harald h.reindl@thelounge.net said:
however, thank you to show me that any discussion with you is worthless
Right back at you.
On Tue, Apr 29, 2014 at 5:28 PM, Chris Adams linux@cmadams.net wrote:
Once upon a time, Reindl Harald h.reindl@thelounge.net said:
however, thank you to show me that any discussion with you is worthless
Right back at you.
The CoC does say a few things on this topic.
I am finding Reindl's trollish behavior extremely annoying. In my reading, 1% of his emails have some value, 99% are just winding people up :-(
Is there a "cool down box" available?
m
Am 29.04.2014 23:33, schrieb Martin Langhoff:
On Tue, Apr 29, 2014 at 5:28 PM, Chris Adams:
Once upon a time, Reindl Harald <h.reindl@thelounge.net: > however, thank you to show me that any discussion with you is worthless Right back at you.The CoC does say a few things on this topic
follow the thread
I am finding Reindl's trollish behavior extremely annoying.
In my reading, 1% of his emails have some value, 99% are just winding people up :-(
ah, i noted security basics, Chris Adams says "no that's wrong" while you say "principles are well understood in this group" which is *obviously* otherwise it would not lead to that long discusssions and proposals like disable the firewall at all and i am trollish?
interesting....
i am not trollish, i just refuse to understand the partly unaccepatble security and change for the sake of the change attitude in many threads - not that i expect anybody get a sepcialist, but sometimes it would be really helpful
On Tue, Apr 29, 2014 at 5:12 PM, Reindl Harald h.reindl@thelounge.netwrote:
defense in depth means limit the attack surface as much as you can
As folks are trying to point out to you, these principles are well understood in this group.
However, _any minimally usable environment will have a scripting engine_ -- /bin/sh, python, and having _any_ of those general purpose tools available is enough for the attacker.
On your own machines, you might gain some (limited) advantage removing some of them.
Fedora and its derivatives, OTOH, are a large enough target that it's worth for attackers to tailor attacks to it. So removing some tools won't do much, and removing _all_ tools will ruin everyone's day.
m
Em 29-04-2014 18:27, Martin Langhoff escreveu:
On Tue, Apr 29, 2014 at 5:12 PM, Reindl Harald <h.reindl@thelounge.net mailto:h.reindl@thelounge.net> wrote:
defense in depth means limit the attack surface as much as you canAs folks are trying to point out to you, these principles are well understood in this group.
However, _any minimally usable environment will have a scripting engine_ -- /bin/sh, python, and having _any_ of those general purpose tools available is enough for the attacker.
On your own machines, you might gain some (limited) advantage removing some of them.
Fedora and its derivatives, OTOH, are a large enough target that it's worth for attackers to tailor attacks to it. So removing some tools won't do much, and removing _all_ tools will ruin everyone's day.
Hm? Okay, thread got long, but I don't recall anybody saying to remove scripting engines & etc. The point always was being able to have docker images without systemd, just because it's just not needed in there, and the thread got drifted away on 'may or not be a security liability'.
It's part of getting Fedora somewhat optimized for containers.
Anyway, sounds like we have even already agreed to remove the Requires, if I'm reading the thread correctly. So yeah, nothing much left to discuss in here ;)
Cheers, Marcelo
On 04/29/2014 05:47 PM, Marcelo Ricardo Leitner wrote:
Em 29-04-2014 18:27, Martin Langhoff escreveu:
On Tue, Apr 29, 2014 at 5:12 PM, Reindl Harald <h.reindl@thelounge.net mailto:h.reindl@thelounge.net> wrote:
defense in depth means limit the attack surface as much as you canAs folks are trying to point out to you, these principles are well understood in this group.
However, _any minimally usable environment will have a scripting engine_ -- /bin/sh, python, and having _any_ of those general purpose tools available is enough for the attacker.
On your own machines, you might gain some (limited) advantage removing some of them.
Fedora and its derivatives, OTOH, are a large enough target that it's worth for attackers to tailor attacks to it. So removing some tools won't do much, and removing _all_ tools will ruin everyone's day.
Hm? Okay, thread got long, but I don't recall anybody saying to remove scripting engines & etc. The point always was being able to have docker images without systemd, just because it's just not needed in there, and the thread got drifted away on 'may or not be a security liability'.
It's part of getting Fedora somewhat optimized for containers.
Anyway, sounds like we have even already agreed to remove the Requires, if I'm reading the thread correctly. So yeah, nothing much left to discuss in here ;)
Cheers, Marcelo
I agree, where do I open a bugzilla to make this happen? rpm? Distro? Systemd?
On 04/30/2014 01:44 PM, Daniel J Walsh wrote:
I agree, where do I open a bugzilla to make this happen? rpm? Distro? Systemd?
Dont you need to first file a change with FPC to the packaging guideline then file bug against every component that has that Require, then provide patches that remove it?
JBG
On Wed, 30.04.14 09:44, Daniel J Walsh (dwalsh@redhat.com) wrote:
On 04/29/2014 05:47 PM, Marcelo Ricardo Leitner wrote:
Em 29-04-2014 18:27, Martin Langhoff escreveu:
On Tue, Apr 29, 2014 at 5:12 PM, Reindl Harald <h.reindl@thelounge.net mailto:h.reindl@thelounge.net> wrote:
defense in depth means limit the attack surface as much as you canAs folks are trying to point out to you, these principles are well understood in this group.
However, _any minimally usable environment will have a scripting engine_ -- /bin/sh, python, and having _any_ of those general purpose tools available is enough for the attacker.
On your own machines, you might gain some (limited) advantage removing some of them.
Fedora and its derivatives, OTOH, are a large enough target that it's worth for attackers to tailor attacks to it. So removing some tools won't do much, and removing _all_ tools will ruin everyone's day.
Hm? Okay, thread got long, but I don't recall anybody saying to remove scripting engines & etc. The point always was being able to have docker images without systemd, just because it's just not needed in there, and the thread got drifted away on 'may or not be a security liability'.
It's part of getting Fedora somewhat optimized for containers.
Anyway, sounds like we have even already agreed to remove the Requires, if I'm reading the thread correctly. So yeah, nothing much left to discuss in here ;)
Cheers, Marcelo
I agree, where do I open a bugzilla to make this happen? rpm? Distro? Systemd?
file a fpc ticket first.
Lennart
On 05/02/2014 06:32 AM, Lennart Poettering wrote:
On Wed, 30.04.14 09:44, Daniel J Walsh (dwalsh@redhat.com) wrote:
On 04/29/2014 05:47 PM, Marcelo Ricardo Leitner wrote:
Em 29-04-2014 18:27, Martin Langhoff escreveu:
On Tue, Apr 29, 2014 at 5:12 PM, Reindl Harald <h.reindl@thelounge.net mailto:h.reindl@thelounge.net> wrote:
defense in depth means limit the attack surface as much as you canAs folks are trying to point out to you, these principles are well understood in this group.
However, _any minimally usable environment will have a scripting engine_ -- /bin/sh, python, and having _any_ of those general purpose tools available is enough for the attacker.
On your own machines, you might gain some (limited) advantage removing some of them.
Fedora and its derivatives, OTOH, are a large enough target that it's worth for attackers to tailor attacks to it. So removing some tools won't do much, and removing _all_ tools will ruin everyone's day.
Hm? Okay, thread got long, but I don't recall anybody saying to remove scripting engines & etc. The point always was being able to have docker images without systemd, just because it's just not needed in there, and the thread got drifted away on 'may or not be a security liability'.
It's part of getting Fedora somewhat optimized for containers.
Anyway, sounds like we have even already agreed to remove the Requires, if I'm reading the thread correctly. So yeah, nothing much left to discuss in here ;)
Cheers, Marcelo
I agree, where do I open a bugzilla to make this happen? rpm? Distro? Systemd?
file a fpc ticket first.
Lennart
I did.
Once upon a time, Reindl Harald h.reindl@thelounge.net said:
simple example:
- binary XYZ is vulerable for privilege escalation
A local, non-privileged binary cannot be "vulerable for privilege escalation". If I can run a non-privileged binary to escalate, then there is a problem with some other part of the system, not the binary. I can (unless severely locked down, which is difficult-to-impossible to do in practice) download another non-privileged binary and achieve the same privilege escalation.
Am 29.04.2014 21:59, schrieb Chris Adams:
Once upon a time, Reindl Harald h.reindl@thelounge.net said:
simple example:
- binary XYZ is vulerable for privilege escalation
A local, non-privileged binary cannot be "vulerable for privilege escalation". If I can run a non-privileged binary to escalate, then there is a problem with some other part of the system, not the binary. I can (unless severely locked down, which is difficult-to-impossible to do in practice) download another non-privileged binary and achieve the same privilege escalation
don't get me wrong but you are talking bullshit
you can't download whatever you like to do in any random situation and excutue it like in a sehll - if you have only *one command* through a web application you need to achieve that this single command triggers the whole attack surface down to the critical component giving you root access
you simply ignore the history of nearly any package coming with security updates and CVE's where it's often even hard to believe "how can this small piece have any security problem at all" ________________________________________
Am 29.04.2014 22:04, schrieb Andrew Lutomirski:
Can you give an actual concrete example of wtf you're talking about? Because I suspect that you're completely wrong, but maybe you're right and no one on this thread understands what you're trying to say.
no i can't give you and example which replaces bother for more than a decade in case of security in a single mailing-list thread
frankly feel free to ignore what people are telling you these people continue also to feel free remove anything un-needed from systems
at the end of the day we will se who was right - the people tyring to make things as secure as possible or the ones which would even not realize a root-exploit on their machines after it has happened because in doubt you have no chance to face it (given that the first thing a rootkit is doing is to manipulate system-commands to hide itself)
Once upon a time, Reindl Harald h.reindl@thelounge.net said:
don't get me wrong but you are talking bullshit
Put up or shut up.
you can't download whatever you like to do in any random situation and excutue it like in a sehll - if you have only *one command* through a web application you need to achieve that this single command triggers the whole attack surface down to the critical component giving you root access
If you can't explain how a non-privileged binary can result in a privilege escalation, then you are wrong. You need to go up-thread and read what I was responding to and show how it is wrong.
Am 29.04.2014 22:22, schrieb Chris Adams:
Once upon a time, Reindl Harald h.reindl@thelounge.net said:
don't get me wrong but you are talking bullshit
Put up or shut up
i shut when i say - not when you say
https://www.google.com/search?q=local+root+exploit+CVE
google as example for CVE-2014-0038 and as i already explained you: a attacker has no shell, you have two ways to force a existing local exploit by a web-application:
A: try to get a complete script on the machine and execute it B: find a very likely present binary and bring it to do the rest of the attack for you with arbitary input
if you find B it's much easier because pass unsanitized input to a web-script calling system() with it is one thing, find a way to create a local file with whatever input you like and execute it finally is a complete different world and needs much more than one security problem in the web-application
you can't download whatever you like to do in any random situation and excutue it like in a sehll - if you have only *one command* through a web application you need to achieve that this single command triggers the whole attack surface down to the critical component giving you root access
If you can't explain how a non-privileged binary can result in a privilege escalation, then you are wrong. You need to go up-thread and read what I was responding to and show how it is wrong.
in case it don't sanitize user input, calling a already running privileged process and feed it with arbitary input damend
do you really pretend that never happened in the past? and no i do not get paied to seek archives for you!
Once upon a time, Reindl Harald h.reindl@thelounge.net said:
google as example for CVE-2014-0038 and as i already explained you: a attacker has no shell, you have two ways to force a existing local exploit by a web-application:
A: try to get a complete script on the machine and execute it B: find a very likely present binary and bring it to do the rest of the attack for you with arbitary input
If I can run arbitrary code as your web user, I can do whatever your web user can do. If your kernel has a security hole, I can exploit that. If I can run PHP code, there's a million things that I can do. If I can run shell code, I can do just about as much. How does the existence of a non-privileged systemd binary affect that?
I understand "defense in depth", I just don't believe the existence of a non-privileged systemd binary has a non-negligible effect on system (or container in this case) security. If I can run an arbitrary binary on your system, you are already owned. I can run /bin/sh (for example, just because it is nearly universal) and fetch other arbitrary binaries.
Do some binaries being available possibly make an attack easier? Maybe, but that work is generally figured out once by "smart" people, and then exploited a million times by script kiddies. Something being "harder" doesn't add anything mcuh to security, because it _can_ be figured out, will be, and then it'll be copy&pasted repeatedly (and you haven't gained a significant advantage from "it is harder").
Am 29.04.2014 23:00, schrieb Chris Adams:
Once upon a time, Reindl Harald h.reindl@thelounge.net said:
google as example for CVE-2014-0038 and as i already explained you: a attacker has no shell, you have two ways to force a existing local exploit by a web-application:
A: try to get a complete script on the machine and execute it B: find a very likely present binary and bring it to do the rest of the attack for you with arbitary input
If I can run arbitrary code as your web user, I can do whatever your web user can do
limited (why limited goes way too off-topic)
If your kernel has a security hole, I can exploit that
surely, the point is how easy i can do that, do the instructions somewhere how to do that work or not because they contain a command / binary not available on the target system
If I can run PHP code, there's a million things that I can do. If I can run shell code, I can do just about as much. How does the existence of a non-privileged systemd binary affect that?
given index.php?dumb_param=exploit_code
dumb_param gives exploit_code to shell_exec() or like function you can't do whatever you like here simply be escaping
so you are very limited with your command finally you need a abstraction in form of a binary doing harm with the input which you can't pass directly to shell_exec limited by input quoting
I understand "defense in depth"
good
I just don't believe the existence of a non-privileged systemd binary has a non-negligible effect on system (or container in this case) security. If I can run an arbitrary binary on your system, you are already owned. I can run /bin/sh (for example, just because it is nearly universal) and fetch other arbitrary binaries.
as explained you can't do that in any situation
Do some binaries being available possibly make an attack easier? Maybe, but that work is generally figured out once by "smart" people, and then exploited a million times by script kiddies. Something being "harder" doesn't add anything mcuh to security, because it _can_ be figured out, will be, and then it'll be copy&pasted repeatedly (and you haven't gained a significant advantage from "it is harder")
surely because the copy&pasted instrcution may not work if it relies on a default binary not installed in the container
in that case the attacker needs to adopt the exploit only for you or he just goes to a server where his exploit code works out of the box
On Tue, Apr 29, 2014 at 11:09 PM, Reindl Harald h.reindl@thelounge.net wrote:
Am 29.04.2014 23:00, schrieb Chris Adams:
Once upon a time, Reindl Harald h.reindl@thelounge.net said:
google as example for CVE-2014-0038 and as i already explained you: a attacker has no shell, you have two ways to force a existing local exploit by a web-application:
A: try to get a complete script on the machine and execute it B: find a very likely present binary and bring it to do the rest of the attack for you with arbitary input
If I can run arbitrary code as your web user, I can do whatever your web user can do
limited (why limited goes way too off-topic)
If your kernel has a security hole, I can exploit that
surely, the point is how easy i can do that, do the instructions somewhere how to do that work or not because they contain a command / binary not available on the target system
If I can run PHP code, there's a million things that I can do. If I can run shell code, I can do just about as much. How does the existence of a non-privileged systemd binary affect that?
given index.php?dumb_param=exploit_code
dumb_param gives exploit_code to shell_exec() or like function you can't do whatever you like here simply be escaping
so you are very limited with your command
No you are not "very limited" at all ... in case an attacker can inject code like this he pretty much will be able to do whatever that user can do. Unless the script has less privileges then the user (like running in a confined selinux domain).
Attackers generally (and traditionally) try to get a shell (in whatever from) up and running hence why people call code that you inject using stack smashing, heap overflows etc. "shellcode" (it does not have to open a shell but that's the most common case, the second one would be drive by download).
In your case the attacker would try to get a reverse shell (which is easily doable by tons of ways just google for it).
So a statement like "you are very limited with your command" here is very naive.
On Tue, Apr 29, 2014 at 4:16 PM, Reindl Harald h.reindl@thelounge.netwrote:
don't get me wrong but you are talking bullshit
Reindl, your SNR is way way high. Maybe try sending /less/ emails, concentrating in being clear and helpful?
Don't worry, there is _always_ someone who's wrong on the internet. You can't address all of them... keep in mind, in some cases you are the one who isn't fully understanding the topic...
cheers,
m
On Tue, 29.04.14 15:36, Marcelo Ricardo Leitner (marcelo.leitner@gmail.com) wrote:
Em 29-04-2014 12:27, Lennart Poettering escreveu:
On Tue, 29.04.14 10:37, Daniel J Walsh (dwalsh@redhat.com) wrote:
On 04/29/2014 06:33 AM, Lennart Poettering wrote:
On Mon, 28.04.14 17:01, Daniel J Walsh (dwalsh@redhat.com) wrote:
The problem is lots of services require systemd because they ship a unit file and want systemctl reload to happen. Systemd then triggers a require for udev and kmod, which docker containers do not need.
If you discount the docs/man pages of the RPMs, how much does kmod, udev, systemd actually contribtue in bytes to your docker images?
Lennart
Shrinking the the docker image is more then just size. We want to eliminate packages that are not used (Within reason) to eliminate problems like CVE's. If udev/systemd/kmod had a CVE we would need to update all Container images.
Well, if you are this principled maybe. But do note that we dont really ship suid binaries (except one binary with fscaps which is systemd-detect-virt), and hence by leaving systemd in the image without running it should result in no increased attack surface that wasn't there anyway... Dead code in the image, that cannot be use to acquire new caps isn't much of a security threat...
You're considering only the escalation way to do it, but there are other ways to exploit code laying around, like when some web pages don't sanitize the URL enough and end up allowing executing something in the system, much like sql injection. In those cases, one could craft URLs to run wget or any other tool that may help the intruder get even more inside.
It's a pile of faults, yes, but the result isn't good and one good preventive step is keeping the dead/not needed stuff away.
This makes no sense. I mean, why would anyone bother with playing with systemd's binaries which (with the exceptio of s-d-v, see above) do not increase your set of capabilities when executed, if you have /bin/sh anyway which allows you to do whatever you want? If an attacker managed to inject code in your system, then systemd's tools won't allow him to do anything he couldn't do anyway, either directly with injected code or by invoking /bin/sh and then continuing from there. Hence the attack surface is not increased.
A problem would be tons of suid bianries, or binaries with fscaps. But otherwise dead code lying around is no real additional security threat. I am mostly interested in actual security measures, not security theatre.
Lennart
Em 30-04-2014 07:57, Lennart Poettering escreveu:
On Tue, 29.04.14 15:36, Marcelo Ricardo Leitner (marcelo.leitner@gmail.com) wrote:
Em 29-04-2014 12:27, Lennart Poettering escreveu:
On Tue, 29.04.14 10:37, Daniel J Walsh (dwalsh@redhat.com) wrote:
On 04/29/2014 06:33 AM, Lennart Poettering wrote:
On Mon, 28.04.14 17:01, Daniel J Walsh (dwalsh@redhat.com) wrote:
The problem is lots of services require systemd because they ship a unit file and want systemctl reload to happen. Systemd then triggers a require for udev and kmod, which docker containers do not need.
If you discount the docs/man pages of the RPMs, how much does kmod, udev, systemd actually contribtue in bytes to your docker images?
Lennart
Shrinking the the docker image is more then just size. We want to eliminate packages that are not used (Within reason) to eliminate problems like CVE's. If udev/systemd/kmod had a CVE we would need to update all Container images.
Well, if you are this principled maybe. But do note that we dont really ship suid binaries (except one binary with fscaps which is systemd-detect-virt), and hence by leaving systemd in the image without running it should result in no increased attack surface that wasn't there anyway... Dead code in the image, that cannot be use to acquire new caps isn't much of a security threat...
You're considering only the escalation way to do it, but there are other ways to exploit code laying around, like when some web pages don't sanitize the URL enough and end up allowing executing something in the system, much like sql injection. In those cases, one could craft URLs to run wget or any other tool that may help the intruder get even more inside.
It's a pile of faults, yes, but the result isn't good and one good preventive step is keeping the dead/not needed stuff away.
This makes no sense. I mean, why would anyone bother with playing with systemd's binaries which (with the exceptio of s-d-v, see above) do not increase your set of capabilities when executed, if you have /bin/sh anyway which allows you to do whatever you want? If an attacker managed
Don't ask me, ask when it happens (again)/when the next CVE comes up. (and no, I'm not referring to systemd exclusively)
to inject code in your system, then systemd's tools won't allow him to do anything he couldn't do anyway, either directly with injected code or by invoking /bin/sh and then continuing from there. Hence the attack surface is not increased.
That only if you assume that directly executing the wanted binary (being a file or not) is the only way to do it.
Please, seriously, I'm not saying (and also was not saying so before too, sorry if it wasn't clear) this is the case for systemd. I'm just saying that code that seems dead might not be dead on all circumstances, for whatever reason. That's my only point here.
A problem would be tons of suid bianries, or binaries with fscaps. But
Like tricking an application on sending (mass) emails to (unwanted) addresses or whatever is okay.
otherwise dead code lying around is no real additional security threat. I am mostly interested in actual security measures, not security theatre.
If that's what you think, okay. I do agree with you that suids & all are the worse thing. After all, it's like winning the lottery for hackers and that's probably where they focus most. But still fear something ending up executed via unwanted/unpredicted ways, specially when systems are getting more integrated, clever and smarter day after day.
Marcelo
On Wed, Apr 30, 2014 at 3:56 PM, Marcelo Ricardo Leitner marcelo.leitner@gmail.com wrote:
If that's what you think, okay. I do agree with you that suids & all are the worse thing. After all, it's like winning the lottery for hackers and that's probably where they focus most. But still fear something ending up executed via unwanted/unpredicted ways, specially when systems are getting more integrated, clever and smarter day after day.
If the goal is to close the giant attack surface that setuid things provide, then there's almost an easy solution: use PR_SET_NO_NEW_PRIVS. It's integrated with systemd, but my effort to get it into PAM [1] didn't seem to go anywhere. I think that, for the most part, most daemons should have no_new_privs set.
PAM integration would make it work for services like gitolite and for ordinary shell users who are willing to tolerate minor regressions like being unable to change passwords. :)
[1] http://www.redhat.com/archives/pam-list/2013-October/msg00012.html
--Andy
On Wed, 30.04.14 19:56, Marcelo Ricardo Leitner (marcelo.leitner@gmail.com) wrote:
This makes no sense. I mean, why would anyone bother with playing with systemd's binaries which (with the exceptio of s-d-v, see above) do not increase your set of capabilities when executed, if you have /bin/sh anyway which allows you to do whatever you want? If an attacker managed
Don't ask me, ask when it happens (again)/when the next CVE comes up. (and no, I'm not referring to systemd exclusively)
No, what you are saying technically makes no sense. It really doesn't.
A problem would be tons of suid bianries, or binaries with fscaps. But
Like tricking an application on sending (mass) emails to (unwanted) addresses or whatever is okay.
Which attackers can do anyway. If they manage to inject code into your system, then they manage to inject code into your system, that's it. They won. Theres's effectively no difference in whether let's say they can use the SMTP implementation they already find on the system or whether they have to inject their own: the essence is that if they can execute code then they can execute code, whatever code they like. What would be interesting if they could use dead systemd code to escalate privs. But since we don#t ship any suid/fscaps stuff (modulo s-d-v), that's not the case...
otherwise dead code lying around is no real additional security threat. I am mostly interested in actual security measures, not security theatre.
If that's what you think, okay. I do agree with you that suids & all are the worse thing. After all, it's like winning the lottery for hackers and that's probably where they focus most. But still fear something ending up executed via unwanted/unpredicted ways, specially when systems are getting more integrated, clever and smarter day after day.
Well, that's theatre. It's not security engineering.
Lennart
2014-05-02 12:47 GMT+02:00 Lennart Poettering mzerqung@0pointer.de:
On Wed, 30.04.14 19:56, Marcelo Ricardo Leitner (marcelo.leitner@gmail.com) wrote:
This makes no sense. I mean, why would anyone bother with playing with systemd's binaries which (with the exceptio of s-d-v, see above) do not increase your set of capabilities when executed, if you have /bin/sh anyway which allows you to do whatever you want? If an attacker managed
Don't ask me, ask when it happens (again)/when the next CVE comes up. (and no, I'm not referring to systemd exclusively)
No, what you are saying technically makes no sense. It really doesn't.
<snip>
If they manage to inject code into your system, then they manage to inject code into your system, that's it. They won.
It's not quite *that* simple. The risk being discussed here is arbitrary execution *of a command line* (e.g. string injection into system(3)), when the attacker can run anything available via the namespace but not (yet) upload their own binaries.
That risk *is* real. OTOH until someone demonstrates a fully "productized" application (i.e. suitable for automated setup, configuration management, security updates) that includes none of: shell, python, coreutils, rpm, wget, curl (... and many more tools), I don't think it's practical to spend much effort trying to defend against it; running the suspect code (say, a PHP application) under an isolated UID with limited privileges is a reasonable compromise. Mirek
On tis, 2014-04-29 at 12:33 +0200, Lennart Poettering wrote:
On Mon, 28.04.14 17:01, Daniel J Walsh (dwalsh@redhat.com) wrote:
The problem is lots of services require systemd because they ship a unit file and want systemctl reload to happen. Systemd then triggers a require for udev and kmod, which docker containers do not need.
If you discount the docs/man pages of the RPMs, how much does kmod, udev, systemd actually contribtue in bytes to your docker images?
Its around 15 megs or so, although on rhel7 its 20 megs larger because of a dependency that kmod has on /usr/bin/nm (binutils) that doesn't seem to be there on fedora kmod. This seems like a bug in fedora though, as kmod ships /usr/sbin/weak-modules which calls nm, so once fixed fedora would be at 35 meg too.
But, even if the size is small that is not the full picture. There are a bunch of dependencies like dbus (the daemon), device-mapper, kmod, and iptables that are recursively pulled in by systemd that don't really make sense in a container. Having such things there increases the risk of security issues even if they are not in use (maybe something is setuid?). Furthermore, things being in the base image by "accident" means these packages get cemented into some kind of "ABI" that we probably have to keep forever, as apps could rely on them.
On Tue, Apr 29, 2014 at 10:58 AM, Alexander Larsson alexl@redhat.com wrote:
On tis, 2014-04-29 at 12:33 +0200, Lennart Poettering wrote:
On Mon, 28.04.14 17:01, Daniel J Walsh (dwalsh@redhat.com) wrote:
The problem is lots of services require systemd because they ship a unit file and want systemctl reload to happen. Systemd then triggers a require for udev and kmod, which docker containers do not need.
If you discount the docs/man pages of the RPMs, how much does kmod, udev, systemd actually contribtue in bytes to your docker images?
Its around 15 megs or so, although on rhel7 its 20 megs larger because of a dependency that kmod has on /usr/bin/nm (binutils) that doesn't seem to be there on fedora kmod. This seems like a bug in fedora though, as kmod ships /usr/sbin/weak-modules which calls nm, so once fixed fedora would be at 35 meg too.
It's a bug one way or another. Lacking the dep on nm would break weak-modules as you suggest, but afaik Fedora doesn't ship anything that actually uses or leverages weak-modules anyway. So either the dep could be added or the script could be dropped.
josh
On tis, 2014-04-29 at 11:21 -0400, Josh Boyer wrote:
On Tue, Apr 29, 2014 at 10:58 AM, Alexander Larsson alexl@redhat.com wrote:
On tis, 2014-04-29 at 12:33 +0200, Lennart Poettering wrote:
On Mon, 28.04.14 17:01, Daniel J Walsh (dwalsh@redhat.com) wrote:
The problem is lots of services require systemd because they ship a unit file and want systemctl reload to happen. Systemd then triggers a require for udev and kmod, which docker containers do not need.
If you discount the docs/man pages of the RPMs, how much does kmod, udev, systemd actually contribtue in bytes to your docker images?
Its around 15 megs or so, although on rhel7 its 20 megs larger because of a dependency that kmod has on /usr/bin/nm (binutils) that doesn't seem to be there on fedora kmod. This seems like a bug in fedora though, as kmod ships /usr/sbin/weak-modules which calls nm, so once fixed fedora would be at 35 meg too.
It's a bug one way or another. Lacking the dep on nm would break weak-modules as you suggest, but afaik Fedora doesn't ship anything that actually uses or leverages weak-modules anyway. So either the dep could be added or the script could be dropped.
Another alternative is to use eu-nm, which is part of elfutils, which is not 20 meg.
On Tue, 29.04.14 16:58, Alexander Larsson (alexl@redhat.com) wrote:
On tis, 2014-04-29 at 12:33 +0200, Lennart Poettering wrote:
On Mon, 28.04.14 17:01, Daniel J Walsh (dwalsh@redhat.com) wrote:
The problem is lots of services require systemd because they ship a unit file and want systemctl reload to happen. Systemd then triggers a require for udev and kmod, which docker containers do not need.
If you discount the docs/man pages of the RPMs, how much does kmod, udev, systemd actually contribtue in bytes to your docker images?
Its around 15 megs or so, although on rhel7 its 20 megs larger because of a dependency that kmod has on /usr/bin/nm (binutils) that doesn't seem to be there on fedora kmod. This seems like a bug in fedora though, as kmod ships /usr/sbin/weak-modules which calls nm, so once fixed fedora would be at 35 meg too.
I am pretty sure that the weak-modules thing should just go. It's outdated cruft, for some enterprise thing, and inused in Fedora. I'd really recommend to just drop it from the Fedora package...
But, even if the size is small that is not the full picture. There are a bunch of dependencies like dbus (the daemon), device-mapper, kmod, and iptables that are recursively pulled in by systemd that don't really
device-mapper? iptables? That sounds wrong... Any idea how that gets pulled in? the dm libs might get pulled in indirectly via libcryptsetup, but the other dm tools really shouldn't be. And iptables i really don't see how that's pulled in?
dbus (the daemon) is probably something we can turn around to not require. I mean, it's needed during runtime if you boot a full OS container or host, but I figure we don#t really have to pull this in like this...
Lennart
2014-04-29 17:40 GMT+02:00 Lennart Poettering mzerqung@0pointer.de:
On Tue, 29.04.14 16:58, Alexander Larsson (alexl@redhat.com) wrote:
Its around 15 megs or so, although on rhel7 its 20 megs larger because of a dependency that kmod has on /usr/bin/nm (binutils) that doesn't seem to be there on fedora kmod. This seems like a bug in fedora though, as kmod ships /usr/sbin/weak-modules which calls nm, so once fixed fedora would be at 35 meg too.
I am pretty sure that the weak-modules thing should just go. It's outdated cruft, for some enterprise thing, and inused in Fedora.
That "outdated cruft" is AFAICS still part of the RHEL-7 ABI design. Assuming the same people will end up maintaining it whether it is in Fedora or RHEL-7, I can't see that work going away, though whether to maintain it "upstream" in Fedora or as a RHEL-only patch is basically up to the individual maintainers. Mirek
On Tue, Apr 29, 2014 at 11:47 AM, Miloslav Trmač mitr@volny.cz wrote:
2014-04-29 17:40 GMT+02:00 Lennart Poettering mzerqung@0pointer.de:
On Tue, 29.04.14 16:58, Alexander Larsson (alexl@redhat.com) wrote:
Its around 15 megs or so, although on rhel7 its 20 megs larger because of a dependency that kmod has on /usr/bin/nm (binutils) that doesn't seem to be there on fedora kmod. This seems like a bug in fedora though, as kmod ships /usr/sbin/weak-modules which calls nm, so once fixed fedora would be at 35 meg too.
I am pretty sure that the weak-modules thing should just go. It's outdated cruft, for some enterprise thing, and inused in Fedora.
That "outdated cruft" is AFAICS still part of the RHEL-7 ABI design. Assuming the same people will end up maintaining it whether it is in Fedora or RHEL-7, I can't see that work going away, though whether to maintain it "upstream" in Fedora or as a RHEL-only patch is basically up to the individual maintainers.
Fedora does not, and will not, support the kABI mechanism that is present in the RHEL kernel package. It doesn't make sense in Fedora at all. So "maintaining" weak-modules in Fedora is pretty limited. You can't test what can't be used, as evident by it not even having the proper deps.
josh
On tis, 2014-04-29 at 17:40 +0200, Lennart Poettering wrote:
On Tue, 29.04.14 16:58, Alexander Larsson (alexl@redhat.com) wrote:
On tis, 2014-04-29 at 12:33 +0200, Lennart Poettering wrote:
On Mon, 28.04.14 17:01, Daniel J Walsh (dwalsh@redhat.com) wrote:
The problem is lots of services require systemd because they ship a unit file and want systemctl reload to happen. Systemd then triggers a require for udev and kmod, which docker containers do not need.
If you discount the docs/man pages of the RPMs, how much does kmod, udev, systemd actually contribtue in bytes to your docker images?
Its around 15 megs or so, although on rhel7 its 20 megs larger because of a dependency that kmod has on /usr/bin/nm (binutils) that doesn't seem to be there on fedora kmod. This seems like a bug in fedora though, as kmod ships /usr/sbin/weak-modules which calls nm, so once fixed fedora would be at 35 meg too.
I am pretty sure that the weak-modules thing should just go. It's outdated cruft, for some enterprise thing, and inused in Fedora. I'd really recommend to just drop it from the Fedora package...
But, even if the size is small that is not the full picture. There are a bunch of dependencies like dbus (the daemon), device-mapper, kmod, and iptables that are recursively pulled in by systemd that don't really
device-mapper? iptables? That sounds wrong... Any idea how that gets pulled in? the dm libs might get pulled in indirectly via libcryptsetup, but the other dm tools really shouldn't be. And iptables i really don't see how that's pulled in?
systemd => cryptsetup-libs => device-mapper-libs => device-mapper
Don't have time to look up the details atm, but iptable was reached via initscripts somehow.
On Tue, 29.04.14 18:03, Alexander Larsson (alexl@redhat.com) wrote:
On tis, 2014-04-29 at 17:40 +0200, Lennart Poettering wrote:
On Tue, 29.04.14 16:58, Alexander Larsson (alexl@redhat.com) wrote:
On tis, 2014-04-29 at 12:33 +0200, Lennart Poettering wrote:
On Mon, 28.04.14 17:01, Daniel J Walsh (dwalsh@redhat.com) wrote:
The problem is lots of services require systemd because they ship a unit file and want systemctl reload to happen. Systemd then triggers a require for udev and kmod, which docker containers do not need.
If you discount the docs/man pages of the RPMs, how much does kmod, udev, systemd actually contribtue in bytes to your docker images?
Its around 15 megs or so, although on rhel7 its 20 megs larger because of a dependency that kmod has on /usr/bin/nm (binutils) that doesn't seem to be there on fedora kmod. This seems like a bug in fedora though, as kmod ships /usr/sbin/weak-modules which calls nm, so once fixed fedora would be at 35 meg too.
I am pretty sure that the weak-modules thing should just go. It's outdated cruft, for some enterprise thing, and inused in Fedora. I'd really recommend to just drop it from the Fedora package...
But, even if the size is small that is not the full picture. There are a bunch of dependencies like dbus (the daemon), device-mapper, kmod, and iptables that are recursively pulled in by systemd that don't really
device-mapper? iptables? That sounds wrong... Any idea how that gets pulled in? the dm libs might get pulled in indirectly via libcryptsetup, but the other dm tools really shouldn't be. And iptables i really don't see how that's pulled in?
systemd => cryptsetup-libs => device-mapper-libs => device-mapper
Don't have time to look up the details atm, but iptable was reached via initscripts somehow.
I wonder if we can break the d-m-l → d-m link... If we can't there's probably little reason to have two packages for this...
Lennart
On Tue, 2014-04-29 at 18:14 +0200, Lennart Poettering wrote:
On Tue, 29.04.14 18:03, Alexander Larsson (alexl@redhat.com) wrote:
systemd => cryptsetup-libs => device-mapper-libs => device-mapper
Don't have time to look up the details atm, but iptable was reached via initscripts somehow.
I wonder if we can break the d-m-l → d-m link... If we can't there's probably little reason to have two packages for this...
Appears to have been introduced in:
* Wed Jun 23 2010 Alasdair Kergon agk@redhat.com - 2.02.68-1 - Have device-mapper-libs require device-mapper (circular) for udev rules.
- ajax
devel@lists.stg.fedoraproject.org
-
Adam Jackson -
Alexander Larsson -
Andrew Lutomirski -
Bruno Wolff III -
Chris Adams -
Chuck Anderson -
Colin Walters -
Daniel J Walsh -
drago01 -
Haïkel -
Josh Boyer -
Jóhann B. Guðmundsson -
Kalev Lember -
Lennart Poettering -
Marcelo Ricardo Leitner -
Martin Langhoff -
Matthew Miller -
Miloslav Trmač -
Panu Matilainen -
Reindl Harald -
Richard Hughes -
Stephen John Smoogen -
Tomasz Torcz -
Toshio Kuratomi -
Vít Ondruch -
Zbigniew Jędrzejewski-Szmek