2 ms·
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
by 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.
- ncmncm 5y agoSymbolic links are an overwhelmingly greater problem than just for "file system engineers". If you code a program that does Posix file system operations, and may be used where security matters, congratulations, you are a security hole vector.