Re:Show HN: Credentials dumper for Linux using eBPF
by mdaverde on Tuesday July 05, 2022 @11:30AM
(#31989383)
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
[ Parent
| on HN ]
Re:Show HN: Credentials dumper for Linux using eBPF
by citronneur on Tuesday July 05, 2022 @11:31AM
(#31989400)
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
Re:Show HN: Credentials dumper for Linux using eBPF
by sorcix on Tuesday July 05, 2022 @11:40AM
(#31989549)
Oh, makes sense, thanks!
Re:Show HN: Credentials dumper for Linux using eBPF
by nicce on Tuesday July 05, 2022 @12:20PM
(#31990210)
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.
Re:Show HN: Credentials dumper for Linux using eBPF
by freedomben on Tuesday July 05, 2022 @01:50PM
(#31991417)
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.
Re:Show HN: Credentials dumper for Linux using eBPF
by nicce on Tuesday July 05, 2022 @01:56PM
(#31991525)
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.
Re:Show HN: Credentials dumper for Linux using eBPF
by stevenhuang on Tuesday July 05, 2022 @01:18PM
(#31990989)
The entire point of this program is that it hooks the func inside the libpam.so actively being used by the system for auth...