9 ms·

Well dynamic linking and most things in unix is an afterthought by definition because the first unix system did not have them. That doesn't seem to be what you

Well dynamic linking and most things in unix is an afterthought by definition because the first unix system did not have them. That doesn't seem to be what you mean though in context, but I'm not sure what you do mean. You don't like it or don't think it was designed well because dynamic linking is done in userspace?

userbinator 3y ago
The fact that an executable needs to explicitly specify the "interpreter", instead of that being something under control of the OS loader, doesn't seem like a good way of doing it; and then the implementation of ldd discussed here just takes it in an even weirder direction.
- dap 3y ago
  What distinction are you making? Do you think it should be part of the kernel? I ask because ld.so (the runtime linker/loader) is part of the OS on many systems.
  - userbinator 3y ago
    I mean not explicitly hardcoding the path to the interpreter inside every binary. If the dynamic linker is part of the OS, then surely the OS should already know where it is?
    - throwawaylinux 3y ago
      How much do you actually know about this? Have you read the ELF spec or written anything with libelf, hacked on a loader, a linker? Considered the actual problems with having this hard coded vs alternatives? I ask because ELF and unix dynamic linking is a pretty well thought out set of specifications and processes and it's a huge body of work. It can certainly be criticized, but calling it an afterthought because of .interp doesn't seem very charitable, just trying to understand if that's an informed opinion and if so it would be interesting to hear more.
    - duped 3y ago
      > If the dynamic linker is part of the OS, then surely the OS should already know where it is? It's both part of the OS and the language's compiler tool chain the program was written in. For the vast majority of Linux executables that's glibc and the ld-linux.so that glibc ships. And you don't need to hard code the path inside your executable. Static PIE objects for example are dynamic elf objects without an interpreter header. The system loader is capable of launching them just fine.
    - dap 3y ago
      I’m still not sure what principle you’ve got that’s being violated here? Given that one has chosen to implement part of the runtime linker/loader in userland, what’s wrong with fitting that into a more generic facility (supporting interpreters at arbitrary paths) and putting this specific implementation into a committed path?
- throwawaylinux 3y ago
  > The fact that an executable needs to explicitly specify the "interpreter", instead of that being something under control of the OS loader, doesn't seem like a good way of doing it; The OS loader does control the permissions of what can be read and executed. And the user can execute a file. Why would it be better if you had to execute the loader explicitly to run a program? The same security problem would apply if you convinced somebody else to execute your malicious code. Seems like pretty harmless syntactic convenience. The issue of ldd executing the program I guess is a thing that could be tightened to avoid foot shooting. Lots of unix programs traditionally were happy to give you lots of rope though.
cryptonector 3y ago
It fits perfectly in the Unix philosophy.
- immibis 3y ago
  Sucky working code is better than code that doesn't exist, yes. But isn't it silly that every Linux system needs to place this exact file at this exact path or else no program for another system will possibly be able to run on it?
  - jclulow 3y ago
    The name of the file is just part of the committed interface that the binary consumes. You could just as well suggest it's silly that every Linux system needs to agree on the behaviour of each system call number, or no program for another system will possibly be able to run on it.
  - cryptonector 3y ago
    "But isn't it silly that every Linux system needs a kernel and an initrd image or else it won't boot?"
- pjmlp 3y ago
  Translation, worse is better philosophy.
  - anthk 3y ago
    9front does it better. No dynamic linking. At all.
    - cryptonector 3y ago
      User-land code can always add dynamic linking.
  - cryptonector 3y ago
    Not really. Would you rather that the dynamic linker-loader be part of the kernel? Do you think that the kernel can somehow prohibit user-land dynamic linking?

userbinator 3y ago

The fact that an executable needs to explicitly specify the "interpreter", instead of that being something under control of the OS loader, doesn't seem like a good way of doing it; and then the implementation of ldd discussed here just takes it in an even weirder direction.

dap 3y ago
What distinction are you making? Do you think it should be part of the kernel? I ask because ld.so (the runtime linker/loader) is part of the OS on many systems.
- userbinator 3y ago
  I mean not explicitly hardcoding the path to the interpreter inside every binary. If the dynamic linker is part of the OS, then surely the OS should already know where it is?
  - throwawaylinux 3y ago
    How much do you actually know about this? Have you read the ELF spec or written anything with libelf, hacked on a loader, a linker? Considered the actual problems with having this hard coded vs alternatives? I ask because ELF and unix dynamic linking is a pretty well thought out set of specifications and processes and it's a huge body of work. It can certainly be criticized, but calling it an afterthought because of .interp doesn't seem very charitable, just trying to understand if that's an informed opinion and if so it would be interesting to hear more.
  - duped 3y ago
    > If the dynamic linker is part of the OS, then surely the OS should already know where it is? It's both part of the OS and the language's compiler tool chain the program was written in. For the vast majority of Linux executables that's glibc and the ld-linux.so that glibc ships. And you don't need to hard code the path inside your executable. Static PIE objects for example are dynamic elf objects without an interpreter header. The system loader is capable of launching them just fine.
  - dap 3y ago
    I’m still not sure what principle you’ve got that’s being violated here? Given that one has chosen to implement part of the runtime linker/loader in userland, what’s wrong with fitting that into a more generic facility (supporting interpreters at arbitrary paths) and putting this specific implementation into a committed path?
throwawaylinux 3y ago
> The fact that an executable needs to explicitly specify the "interpreter", instead of that being something under control of the OS loader, doesn't seem like a good way of doing it; The OS loader does control the permissions of what can be read and executed. And the user can execute a file. Why would it be better if you had to execute the loader explicitly to run a program? The same security problem would apply if you convinced somebody else to execute your malicious code. Seems like pretty harmless syntactic convenience. The issue of ldd executing the program I guess is a thing that could be tightened to avoid foot shooting. Lots of unix programs traditionally were happy to give you lots of rope though.

cryptonector 3y ago

It fits perfectly in the Unix philosophy.

immibis 3y ago
Sucky working code is better than code that doesn't exist, yes. But isn't it silly that every Linux system needs to place this exact file at this exact path or else no program for another system will possibly be able to run on it?
- jclulow 3y ago
  The name of the file is just part of the committed interface that the binary consumes. You could just as well suggest it's silly that every Linux system needs to agree on the behaviour of each system call number, or no program for another system will possibly be able to run on it.
- cryptonector 3y ago
  "But isn't it silly that every Linux system needs a kernel and an initrd image or else it won't boot?"
pjmlp 3y ago
Translation, worse is better philosophy.
- anthk 3y ago
  9front does it better. No dynamic linking. At all.
  - cryptonector 3y ago
    User-land code can always add dynamic linking.
- cryptonector 3y ago
  Not really. Would you rather that the dynamic linker-loader be part of the kernel? Do you think that the kernel can somehow prohibit user-land dynamic linking?