4 ms·

One of my favorite things about NixOS is how easy it makes it to not use shared libraries, AKA the most brain-damaged, over-used, needlessly complex, crime agai

One of my favorite things about NixOS is how easy it makes it to not use shared libraries, AKA the most brain-damaged, over-used, needlessly complex, crime against computing in common use. There are good reasons to use LXC and namespaces and shit, but mostly Docker is a workaround for how fucking stupid dynamic linking is as a default. There are even use cases for .so, but as a default? Someone should be flogged. It was stupid when Sun pushed it with X in the 90s, and it’s stupider now. Also, gold/mold are worth trying in addition to lld. Depends on your software.

ncmncm 5y ago
Here I thought symbolic links were "the most brain-damaged, over-used, needlessly complex, crime against computing in common use." I am not making this up, ask Jeremy Allison, who is in a position to know. Using Nix without relying on symbolic links would be ... challenging.
- colordrops 5y ago
  What's the alternative?
  - benreesman 5y ago
    Nix/NixOS is an alternative, but as I've mentioned elsewhere in the thread it's got major, major downsides. Excluding that, you can go the Alpine/Docker route, which isn't terrible but isn't great. Or you can rebuild your box via Ansible or whatever every time you need a new AMI. This is actually a pretty reasonable solution.
    - colordrops 5y ago
      Wait, I thought you were criticizing Nix because it uses symbolic links. I originally used Absible but switched to Nix. I found ansible to be too idiosyncratic and brittle to maintain. It also isn't inherently idempotent though it's supposed to be used that way.
      - benreesman 5y ago
        I believe it's `ncmncm` who is mounting a credible argument against the existence and use of symbolic links. I'm the "fuck dynamic linking by default" guy.
- benreesman 5y ago
  Symbolic links can be a pain in the ass, but they're comprehensible and serve a purpose. Most importantly, they're pretty opt-in. Now maybe that means you opted in because you're using a piece of software like NixOS that can't work without them, but they don't infect everything and spread like Kudzu. The `glibc` people won't even make it work properly without being an `.so`. I appreciate that the GCC people are desperately trying to hold on to relevance in the face of a much better toolchain, but at what point does the FSF die a hero or live long enough to become the villain it was trying to conquer? Jeremy is a bright guy and I have huge respect for him. And I know the `cat-v` folks troll a bit much, but there is some real substance to linked set of arguments [0]. And it very much ties out with my experience. In the glory days at FB we statically linked everything, and it was amazing. I don't know this firsthand but I've heard it secondhand, and given that we plagiarized basically everything else from Google in those days, I tend to believe the claims that Google did the same. “I tend to think the drawbacks of dynamic linking outweigh the advantages for many (most?) applications.” – John Carmack [0] http://harmful.cat-v.org/software/dynamic-linking/ http://harmful.cat-v.org/software/dynamic-linking/
  - ncmncm 5y ago
    There is no question but that symbolic links are convenient for users. Apparently the problem is that file-system operations on file systems that allow them, or that allow them to be changed, cannot be made secure. Maybe if you could turn off everybody's rights to create or delete symlinks, they would become less problematic. Maybe, have a mount option you could toggle on just when you need to change some, and turn it off again right away. Dynamic linking used to be a big optimization thing -- saved on disk space, saved on virtual-memory footprint; nowadays we hardly notice. Next, it meant you didn't need to rebuild everything when a library got a fix or backward-compatible improvement. Then, it became a way to get security patches into use quickly. It is kind of impressive that we don't (often?) see dynamic linking itself used as an attack vector, aside from bugs in the libraries so linked.
    - benreesman 5y ago
      Eh, I will respectfully disagree on a couple of points. Silently patching `.so` code actually obscures whether or not you have the relevant security fix to the relevant library. `libfoo.0 -> libfoo.0.1 -> libfoo -> 0.1.3` would be confusing enough even if vendors didn't routinely change the code out from underneath without moving the "version". If you're linking a `libfoo.a`, not only does the hash of that file change when it gets updated (or was failed to be updated), but the hash of your resulting binary that you choose to run either did or did not change. You don't need NixOS for that. No `LD_PRELOAD` crap can get in front of you because someone grabbed control of environment variables. There's like a zillion less things to go wrong from a security perspective. And even then, the security that you get from running a binary you built against someone who is already on your machine, and already has enough permissions to run it? You're in murky territory already. Keep them out of your box unless you're a cloud provider or something. I'm no FS expert and I'm prepared to believe that symlinks might create problems for filesystem engineers, but you also sort of need them if you want atomic FS operations on POSIX. Something being a standard isn't a blank check to be bad obviously, but it's a lot easier to change whether or not `glibc` breaks on purpose when statically linked than to change a 30-year-old standard. Dynamic linking is a nightmare for a number of reasons: it makes it murky and difficult to know what code is running, it makes effective text segments depend on environment variables, it further privileges superuser, it destroys the portability/backwards-compatibility that Linus has fought so hard to preserve in the kernel, it miseducates people about how virtual memory works by leading them to assume that it's some kind of performance win (it's not), it complicates the whole system by a ridiculous amount, it requires that you `readelf -d thing` to even know what crazy `rpath` shit is going on. Symlinks have problems, I've been burned by them. But you can use them or not as you like, and the complexity is manageable. You show me a serious hacker, I'll show you someone who can get symlinks substantially right. You show me someone who really, really deeply understands what the hell is going on with dynamic linking? I'll show you Ulrich Drepper and his weird agenda around suppressing LLVM.
MereInterest 5y ago
Shared libraries mean that when there's a security issue, I can update the system's version of the library, restart all programs that use it, and have a fully patched system. If everything is statically linked, I would instead need to identify the library version in use for every binary, then get a patched version of each. Dynamic linking is a tool to improve system administration.
- benreesman 5y ago
  Dynamic linking is a way to get opaque updates from vendors that may or may not have the patch you want, may or may not have a new CVE that you don't want, and have a very difficult time knowing if the code that's going to run when you invoke a given executable is the same or different from what you ran last time and how.

ncmncm 5y ago

Here I thought symbolic links were "the most brain-damaged, over-used, needlessly complex, crime against computing in common use." I am not making this up, ask Jeremy Allison, who is in a position to know. Using Nix without relying on symbolic links would be ... challenging.

colordrops 5y ago
What's the alternative?
- benreesman 5y ago
  Nix/NixOS is an alternative, but as I've mentioned elsewhere in the thread it's got major, major downsides. Excluding that, you can go the Alpine/Docker route, which isn't terrible but isn't great. Or you can rebuild your box via Ansible or whatever every time you need a new AMI. This is actually a pretty reasonable solution.
  - colordrops 5y ago
    Wait, I thought you were criticizing Nix because it uses symbolic links. I originally used Absible but switched to Nix. I found ansible to be too idiosyncratic and brittle to maintain. It also isn't inherently idempotent though it's supposed to be used that way.
    - benreesman 5y ago
      I believe it's `ncmncm` who is mounting a credible argument against the existence and use of symbolic links. I'm the "fuck dynamic linking by default" guy.
benreesman 5y ago
Symbolic links can be a pain in the ass, but they're comprehensible and serve a purpose. Most importantly, they're pretty opt-in. Now maybe that means you opted in because you're using a piece of software like NixOS that can't work without them, but they don't infect everything and spread like Kudzu. The `glibc` people won't even make it work properly without being an `.so`. I appreciate that the GCC people are desperately trying to hold on to relevance in the face of a much better toolchain, but at what point does the FSF die a hero or live long enough to become the villain it was trying to conquer? Jeremy is a bright guy and I have huge respect for him. And I know the `cat-v` folks troll a bit much, but there is some real substance to linked set of arguments [0]. And it very much ties out with my experience. In the glory days at FB we statically linked everything, and it was amazing. I don't know this firsthand but I've heard it secondhand, and given that we plagiarized basically everything else from Google in those days, I tend to believe the claims that Google did the same. “I tend to think the drawbacks of dynamic linking outweigh the advantages for many (most?) applications.” – John Carmack [0] http://harmful.cat-v.org/software/dynamic-linking/ http://harmful.cat-v.org/software/dynamic-linking/
- ncmncm 5y ago
  There is no question but that symbolic links are convenient for users. Apparently the problem is that file-system operations on file systems that allow them, or that allow them to be changed, cannot be made secure. Maybe if you could turn off everybody's rights to create or delete symlinks, they would become less problematic. Maybe, have a mount option you could toggle on just when you need to change some, and turn it off again right away. Dynamic linking used to be a big optimization thing -- saved on disk space, saved on virtual-memory footprint; nowadays we hardly notice. Next, it meant you didn't need to rebuild everything when a library got a fix or backward-compatible improvement. Then, it became a way to get security patches into use quickly. It is kind of impressive that we don't (often?) see dynamic linking itself used as an attack vector, aside from bugs in the libraries so linked.
  - benreesman 5y ago
    Eh, I will respectfully disagree on a couple of points. Silently patching `.so` code actually obscures whether or not you have the relevant security fix to the relevant library. `libfoo.0 -> libfoo.0.1 -> libfoo -> 0.1.3` would be confusing enough even if vendors didn't routinely change the code out from underneath without moving the "version". If you're linking a `libfoo.a`, not only does the hash of that file change when it gets updated (or was failed to be updated), but the hash of your resulting binary that you choose to run either did or did not change. You don't need NixOS for that. No `LD_PRELOAD` crap can get in front of you because someone grabbed control of environment variables. There's like a zillion less things to go wrong from a security perspective. And even then, the security that you get from running a binary you built against someone who is already on your machine, and already has enough permissions to run it? You're in murky territory already. Keep them out of your box unless you're a cloud provider or something. I'm no FS expert and I'm prepared to believe that symlinks might create problems for filesystem engineers, but you also sort of need them if you want atomic FS operations on POSIX. Something being a standard isn't a blank check to be bad obviously, but it's a lot easier to change whether or not `glibc` breaks on purpose when statically linked than to change a 30-year-old standard. Dynamic linking is a nightmare for a number of reasons: it makes it murky and difficult to know what code is running, it makes effective text segments depend on environment variables, it further privileges superuser, it destroys the portability/backwards-compatibility that Linus has fought so hard to preserve in the kernel, it miseducates people about how virtual memory works by leading them to assume that it's some kind of performance win (it's not), it complicates the whole system by a ridiculous amount, it requires that you `readelf -d thing` to even know what crazy `rpath` shit is going on. Symlinks have problems, I've been burned by them. But you can use them or not as you like, and the complexity is manageable. You show me a serious hacker, I'll show you someone who can get symlinks substantially right. You show me someone who really, really deeply understands what the hell is going on with dynamic linking? I'll show you Ulrich Drepper and his weird agenda around suppressing LLVM.

MereInterest 5y ago

Shared libraries mean that when there's a security issue, I can update the system's version of the library, restart all programs that use it, and have a fully patched system. If everything is statically linked, I would instead need to identify the library version in use for every binary, then get a patched version of each. Dynamic linking is a tool to improve system administration.

benreesman 5y ago
Dynamic linking is a way to get opaque updates from vendors that may or may not have the patch you want, may or may not have a new CVE that you don't want, and have a very difficult time knowing if the code that's going to run when you invoke a given executable is the same or different from what you ran last time and how.