4 ms·

> built as a static binary without any dependencies > As pamspy rely on libpam, we have to set the path where libpam is installed on your distribution. Confus

by sorcix 4y ago

> built as a static binary without any dependencies > As pamspy rely on libpam, we have to set the path where libpam is installed on your distribution. Confusing text in the readme. Does it have dependencies or not?

mdaverde 4y ago
I read this as, due to pamspy setting an eBPF probe, pamspy needs to know where libpam.so lives. Not that the pamspy needs libpam to be built
- citronneur 4y ago
  Exactly, we have to found the address to hook on the system, so we need the path of the currently use of libpam by other process
  - sorcix 4y ago
    Oh, makes sense, thanks!
- nicce 4y ago
  It is still quite confusing. > built as a static binary without any dependencies Static binaries are explicitly used for removing the need for specific dynamic runtime dependencies. It does not refer to build dependencies, which are not interesting here. Based on the terms, I would except that libpam is included for the final binary.
  - stevenhuang 4y ago
    The entire point of this program is that it hooks the func inside the libpam.so actively being used by the system for auth...
  - freedomben 4y ago
    If libpam was compiled in, then this tool would do nothing. libpam is not a library for this tool, it's a target, like an input file. libpam is a library for the kernel of the target system. this tool hooks into it to do its work.
    - nicce 4y ago
      Exactly, it is the target. The later phrase pointed out in the original comment it to be some sort of dependency for runtime use, making the confusion. While it is not related to runtime code functionality at all.
semiquaver 4y ago
When the author says it “has no dependencies” they are referring to build time dependencies (i.e. development headers) and runtime library dependencies (dynamic libraries that will be linked and used at runtime). In this case the function of the program is to hook a library function in `libpam` using eBPF so it has libpam as a “dependency” in roughly the same way that a program which converts wav to mp3 depends on “the input wav file”. Given that this is a somewhat unusual way to depend on a `.so` file it’s reasonable for there to be some ambiguity in the language here.
alias_neo 4y ago
You could say libpam is the "target". Like pointing a disassembler at a shared library, it's not needed to run the disassembler, it's the thing you're disassembling.

by sorcix 4y ago

mdaverde 4y ago

I read this as, due to pamspy setting an eBPF probe, pamspy needs to know where libpam.so lives. Not that the pamspy needs libpam to be built

citronneur 4y ago
Exactly, we have to found the address to hook on the system, so we need the path of the currently use of libpam by other process
- sorcix 4y ago
  Oh, makes sense, thanks!
nicce 4y ago
It is still quite confusing. > built as a static binary without any dependencies Static binaries are explicitly used for removing the need for specific dynamic runtime dependencies. It does not refer to build dependencies, which are not interesting here. Based on the terms, I would except that libpam is included for the final binary.
- stevenhuang 4y ago
  The entire point of this program is that it hooks the func inside the libpam.so actively being used by the system for auth...
- freedomben 4y ago
  If libpam was compiled in, then this tool would do nothing. libpam is not a library for this tool, it's a target, like an input file. libpam is a library for the kernel of the target system. this tool hooks into it to do its work.
  - nicce 4y ago
    Exactly, it is the target. The later phrase pointed out in the original comment it to be some sort of dependency for runtime use, making the confusion. While it is not related to runtime code functionality at all.

semiquaver 4y ago

When the author says it “has no dependencies” they are referring to build time dependencies (i.e. development headers) and runtime library dependencies (dynamic libraries that will be linked and used at runtime). In this case the function of the program is to hook a library function in `libpam` using eBPF so it has libpam as a “dependency” in roughly the same way that a program which converts wav to mp3 depends on “the input wav file”. Given that this is a somewhat unusual way to depend on a `.so` file it’s reasonable for there to be some ambiguity in the language here.

alias_neo 4y ago

You could say libpam is the "target". Like pointing a disassembler at a shared library, it's not needed to run the disassembler, it's the thing you're disassembling.