Email or username:

Password:

Forgot your password?
Top-level
Lennart Poettering

@TheStroyer … which think that things like pluggable client-side modules, LDAP and so on are actually a good thing, even though I would vehemently disagree with that.

11 comments
Dave Anderson replied to Lennart

@pid_eins Same disagreement here. But also iirc policykit is extensible right? So if someone is brave enough they could probably extend pk with whatever things they want, and then it can apply to all privilege escalation not just run0!

Maybe I shouldn't give people ideas...

Lennart Poettering replied to Dave

@danderson PK is scriptable with JS, so people kinda can do any kind of shit with it, of course. But I think it's much less problematic than what sudo is doing, because PK runs that stuff in a well defined execution context forked off PK's service which runs unprivileged – and not on the client side, in an icky, undefined, half-inherited mess of an execution context under user control – like sudo does it.

Dave Anderson replied to Lennart

@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.

Dave Anderson replied to Dave

@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...

Lennart Poettering replied to Dave

@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:

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.

Dave Anderson replied to Lennart

@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!

Simo ✔️ replied to Dave

@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).

TheStroyer replied to Lennart

@pid_eins So the intention for it to be a replacement for sudo right? I.e. sudo does not need to be present on a system.

TSRBerry replied to Lennart

@pid_eins Could you expand on the LDAP thing?
Are you saying LDAP is a bad thing in general or how authentication works with it?

leo vriscrab² (homestuck) :dado_verified: replied to TSRBerry

@tsrberry @pid_eins i assume it's referring to how the LDAP implementation ends up running in-process in everything that uses NSS (in the absence of nscd/etc) instead of in its own daemon?

Go Up