11 ms·

Honest question: what's the difference between storing dependencies in the executable (statically) and storing them in the Docker image?

buildbuildbuild 6y ago
Not much besides the convenience of not needing to research/implement compiling something statically.
jbergknoff 6y ago
This isn't exactly "the difference", but some advantages of distributing software in Docker images include cross-platform support and a uniform sandboxing interface. I wrote more about this here: https://jonathan.bergknoff.com/journal/run-more-stuff-in-docker/ https://jonathan.bergknoff.com/journal/run-more-stuff-in-doc...
- shoo 6y ago
  Maybe to rephrase the original question: given that you've already decided to distribute your software as a container image, what is the advantage of storing dependencies in an executable (statically) inside the container image vs storing them some other way inside in the container image?
  - peterwwillis 6y ago
    Basically, it's like distributing a single static binary in a tar file, versus distributing a dynamic binary and all its dependencies in a tar file. The whole purpose of using a tar file is to keep multiple files. You can make a smaller tar file by including just the static file (less inodes/wasted file space of deps linking to each other/unnecessary extra function call data). And technically static files can sometimes execute faster (depending on page/cpu cache etc). But the advantages of static are much smaller when you consider the advantages to dynamic in a tar file - and even more advantages in a container. So while there can be advantageous, they are vanishingly small.
wahern 6y ago
When statically linking the linker can exclude functions that aren't referenced (directly or indirectly) by the main application. For something like libc or, especially, the C++ standard library many and often even most routines can be excluded. OTOH, container images seem to be bloated by unused binaries and completely unused libraries, not unused functions in shared libraries.
- shoo 6y ago
  What are the main advantages of excluding unnecessary library functions / libraries / executables? Here are some possible advantages I can think of: less surface area for security, less surface area for maintenance, smaller container image, implying faster time to pull image, and perhaps also faster time to boot image. Disadvantages: you have to do the work to set it up in the first place and maintain it (putting in extra effort to avoid adding superfluous dependencies in future), while the above advantages may be marginal.
  - wahern 6y ago
    One advantage I've recently encountered is that CVE scanners like Nessus or Stackrox seem to be naive. They don't seem to examine binaries for statically linked libraries, so a container with only a single statically linked binary is likely to stay nominally CVE-free in perpetuity. This might also be true if you simply copy shared libraries. AFAICT these scanners rely on the package index to identify potential CVE exploits. But I may be wrong, and in any event it'd be much more difficult to identify the version of a statically linked library than a shared library, which can be identified by its name or hash. This doesn't excuse avoiding keeping containers updated, but if you want to be cynical about vulnerability management, i.e. that any trick which improves the signal-to-noise ratio is worth exploring, then it's something to keep in mind.
    - pabs3 6y ago
      It sounds like static linking would also hide CVEs that do affect the functions that were compiled into and are used by your statically linked binary in a way that would introduce security issues for that binary. BTW IIRC normal static linking doesn't strip out all unused functions, you need LTO (Link Time Optimisation) to do that.
philsnow 6y ago
You don't have to build the executable yourself. You can just apt-get install whatever and then bundle only the shared libraries used by whatever particular executable you care about (for instance, moreutils includes a ton of tools, maybe you only care about `vidir`, and `vidir` probably doesn't need all the libraries that `isutf8` (also packaged by moreutils) uses). I did this just recently by hand when I wanted to run a source-only binary in my dom0 but didn't want to build it in the dom0. I built it in a container, checked what shared libraries it wanted with `ldd path/to/binary` inside the container, copied all of the referenced libraries to ~/libs, then copied that dir and the binary to dom0 and ran it with `LD_LIBARARY_PATH=$HOME/libs path/to/binary`, worked perfectly.
zapttt 6y ago
it's two different techniques to achieve the same goal: to run badly maintened, outdated software lacking security updates, no matter how well the user maintains and updates the computer.
brigandish 6y ago
It's a good question and one not answered by the README. The very first thing I add to any README now is a heading "Why?" (usually along with "What?" (is it)) because I often land on a piece of software's home page and after reading I still don't know how it would benefit me or why it has been created. The easiest way would be a before and after kind of thing but just a line or two can be a help. The 5 W's[1] aren't just for journalists. [1] https://en.wikipedia.org/wiki/Five_Ws https://en.wikipedia.org/wiki/Five_Ws
viraptor 6y ago
There's one against static linking in development or with lots of deployments: You can't use layers efficiently. With shared deps you can install them before the app itself. With static linking your last layer always includes both, making it larger and slower to down/up-load.
choeger 6y ago
In the former case you could have two closely related programs, say a DB server and its CLI stored efficiently.
etaioinshrdlu 6y ago
Beyond a method of software distribution, docker containers are also a nice sandbox. Apps run inside docker will have very limited access to the rest of the system unless you explicitly give access.
- beagle3 6y ago
  But don’t assume it is a security perimeter, mostly because the docket developers don’t. It’s a lock on the door - keeps honest people honest and erroneous rm -rf confined. But it might not stop a determined hacker.
- yellowbat 6y ago
  Not at all. Docker is a security disaster.
- JustFinishedBSG 6y ago
  Sandboxing should be left to the OS/User and not part of the "binary" distribution method imo

buildbuildbuild 6y ago

Not much besides the convenience of not needing to research/implement compiling something statically.

jbergknoff 6y ago

This isn't exactly "the difference", but some advantages of distributing software in Docker images include cross-platform support and a uniform sandboxing interface. I wrote more about this here: https://jonathan.bergknoff.com/journal/run-more-stuff-in-docker/ https://jonathan.bergknoff.com/journal/run-more-stuff-in-doc...

shoo 6y ago
Maybe to rephrase the original question: given that you've already decided to distribute your software as a container image, what is the advantage of storing dependencies in an executable (statically) inside the container image vs storing them some other way inside in the container image?
- peterwwillis 6y ago
  Basically, it's like distributing a single static binary in a tar file, versus distributing a dynamic binary and all its dependencies in a tar file. The whole purpose of using a tar file is to keep multiple files. You can make a smaller tar file by including just the static file (less inodes/wasted file space of deps linking to each other/unnecessary extra function call data). And technically static files can sometimes execute faster (depending on page/cpu cache etc). But the advantages of static are much smaller when you consider the advantages to dynamic in a tar file - and even more advantages in a container. So while there can be advantageous, they are vanishingly small.

wahern 6y ago

When statically linking the linker can exclude functions that aren't referenced (directly or indirectly) by the main application. For something like libc or, especially, the C++ standard library many and often even most routines can be excluded. OTOH, container images seem to be bloated by unused binaries and completely unused libraries, not unused functions in shared libraries.

shoo 6y ago
What are the main advantages of excluding unnecessary library functions / libraries / executables? Here are some possible advantages I can think of: less surface area for security, less surface area for maintenance, smaller container image, implying faster time to pull image, and perhaps also faster time to boot image. Disadvantages: you have to do the work to set it up in the first place and maintain it (putting in extra effort to avoid adding superfluous dependencies in future), while the above advantages may be marginal.
- wahern 6y ago
  One advantage I've recently encountered is that CVE scanners like Nessus or Stackrox seem to be naive. They don't seem to examine binaries for statically linked libraries, so a container with only a single statically linked binary is likely to stay nominally CVE-free in perpetuity. This might also be true if you simply copy shared libraries. AFAICT these scanners rely on the package index to identify potential CVE exploits. But I may be wrong, and in any event it'd be much more difficult to identify the version of a statically linked library than a shared library, which can be identified by its name or hash. This doesn't excuse avoiding keeping containers updated, but if you want to be cynical about vulnerability management, i.e. that any trick which improves the signal-to-noise ratio is worth exploring, then it's something to keep in mind.
  - pabs3 6y ago
    It sounds like static linking would also hide CVEs that do affect the functions that were compiled into and are used by your statically linked binary in a way that would introduce security issues for that binary. BTW IIRC normal static linking doesn't strip out all unused functions, you need LTO (Link Time Optimisation) to do that.

philsnow 6y ago

You don't have to build the executable yourself. You can just apt-get install whatever and then bundle only the shared libraries used by whatever particular executable you care about (for instance, moreutils includes a ton of tools, maybe you only care about `vidir`, and `vidir` probably doesn't need all the libraries that `isutf8` (also packaged by moreutils) uses). I did this just recently by hand when I wanted to run a source-only binary in my dom0 but didn't want to build it in the dom0. I built it in a container, checked what shared libraries it wanted with `ldd path/to/binary` inside the container, copied all of the referenced libraries to ~/libs, then copied that dir and the binary to dom0 and ran it with `LD_LIBARARY_PATH=$HOME/libs path/to/binary`, worked perfectly.

zapttt 6y ago

it's two different techniques to achieve the same goal: to run badly maintened, outdated software lacking security updates, no matter how well the user maintains and updates the computer.

brigandish 6y ago

It's a good question and one not answered by the README. The very first thing I add to any README now is a heading "Why?" (usually along with "What?" (is it)) because I often land on a piece of software's home page and after reading I still don't know how it would benefit me or why it has been created. The easiest way would be a before and after kind of thing but just a line or two can be a help. The 5 W's[1] aren't just for journalists. [1] https://en.wikipedia.org/wiki/Five_Ws https://en.wikipedia.org/wiki/Five_Ws

viraptor 6y ago

There's one against static linking in development or with lots of deployments: You can't use layers efficiently. With shared deps you can install them before the app itself. With static linking your last layer always includes both, making it larger and slower to down/up-load.

choeger 6y ago

In the former case you could have two closely related programs, say a DB server and its CLI stored efficiently.

etaioinshrdlu 6y ago

Beyond a method of software distribution, docker containers are also a nice sandbox. Apps run inside docker will have very limited access to the rest of the system unless you explicitly give access.

beagle3 6y ago
But don’t assume it is a security perimeter, mostly because the docket developers don’t. It’s a lock on the door - keeps honest people honest and erroneous rm -rf confined. But it might not stop a determined hacker.
yellowbat 6y ago
Not at all. Docker is a security disaster.
JustFinishedBSG 6y ago
Sandboxing should be left to the OS/User and not part of the "binary" distribution method imo