|
Top-level
 @pid_eins 100% yes. N:M dlopen() in unpredictable contexts should really go away as a plugin mechanism, it's so easy to create massive problems. I saw some distros try to fix PAM this way too, they (ab)use the nscd caching protocol in glibc to move all lookups into a system daemon, and hide the .so's from the rest of the system. Same idea, move all the scary plugin stuff to a central location where you can manage it more safely. 4 comments
 @danderson from my perspective as a systemd person I wouldn't ask for that from glibc. We have nss-systemd these days which is an IPC frontend to the generic varlink IPC API described here: https://systemd.io/USER_GROUP_API Anyone can plug in their stuff there. It's generic, extensible and IPC based. Unless you are a systemd hater I see no reason why we'd need to shove that into glibc. @pid_eins Ooh, TIL! I didn't know about this entire subsystem of systemd. My worry was going to be what to do with the cursed legacy modules that some people have, but I see with userdbd there's bidirectional compatibility between varlink and nss clients. Very nice, and yes I agree this is a better way to set up the system. I look forward to the posts for next release, I'm even learning stuff about older releases! @danderson @pid_eins if later systemd is not enough sssd has provided this service with proper caching for almost 15 years. It was built specifically for 3 reasons: consistent caching, remove unwanted libraries from binaries, allow centally controlled private credentials. Because it predates systemd it has its own protcol but also a fast, mmaped shared cache that avoid process context switching when not needed. (full disclosure I am the original author). |
Gregory's Server
@pid_eins Looks like there was a short discussion on the glibc ML in 2022 about formalizing this interface and explicitly support the privilege separation use case, but I'm not sure if anything more happened since...