News for hackers. Stuff that matters.

A comment on Rethinking the filesystem as global mutable state, the root of all evil. Parent comment

Re:Rethinking the filesystem as global mutable state, the ro... by AstralStorm on Tuesday June 11, 2019 @10:30AM (#20155718)
Do they now? Usually, the linker does all the loading, also known in Linux as ld.so. (even when you use dlopen)

Lazy loading can thunk through kernel so that ld.so service loads things into the process - and preferably strict loading should be used.

[ Parent | on HN ]
Re:Rethinking the filesystem as global mutable state, the ro... by mnw21cam on Tuesday June 11, 2019 @10:32AM (#20155737)
Indeed. But ld.so runs in the context of the process that is starting up, so if it doesn't have access to anything, it can't.
[ Parent | on HN ]
Re:Rethinking the filesystem as global mutable state, the ro... by AstralStorm on Tuesday June 11, 2019 @10:34AM (#20155763)
It doesn't actually have to, but you'd need a fun bit of stub code in place of unloaded function pointers etc.
[ Parent | on HN ]
Re:Rethinking the filesystem as global mutable state, the ro... by pjc50 on Tuesday June 11, 2019 @10:37AM (#20155797)
Not a useful distinction, since it needs to be visible inside the chroot either way. Not only that but libc via getpwnam() and friends needs to access PAM and thence all the libpam modules.
[ Parent | on HN ]
Re:Rethinking the filesystem as global mutable state, the ro... by mnw21cam on Tuesday June 11, 2019 @10:47AM (#20155894)
That also depends. I have a chroot set up here to run sftp-server for incoming ssh connections, and it has 55 files in it, 40 of which appear to be libraries - none of them having anything to do with PAM.
[ Parent | on HN ]