@paco systemd: the gift that keeps giving.
Systemd is, in this case, apparently overriding other system permission controls because the auth system they are using said it was OK.
Reducing trust would seem to be a minimum necessary response here, but instead the response is "not a bug in our code, not our problem".
@RandomDamage @jerry @paco systemd is doing nothing with authentication here. Again: It is a polkit bug. Polkit is the authentication system that accepts that.
I don't know the details, but In guess polkit executes the command, not systemd.
And this is obviously not their bug, so it is absolutely okay, to close this as "this is a polkit bug".
If you know more details about the architecture or what needs to be changed, then open a new issue or so.
@rugk @jerry Yeah, I don't agree with
@RandomDamage . Systemd is fundamentally doing a reasonable thing: trusting a subsystem whose job it is to authenticate users. That subsystem, sadly, fails open. I mean an ASSERTION is exactly the kind of failure that you should fail closed on. It's literally a failure of a foundational assumption. Systemd does not make a mistake by trusting polkit.
The standard is a bit higher for that sort of thing.
Besides, there are distributions that have moved away from OpenSSL over the security bugs there. It is a reasonable thing to do.
There's a difference between theory and practice. It's all well and good to spout a first principle like "it shouldn't trust polkit" but that lack of trust has to manifest in specific code behaviour. If we "don't trust" polkit, what do we do? Implement AuthN ourselves? That way leads to tears. And @rugk's analogy to OpenSSL is a good one. I hate systemd as much as any BSD guy might. But in THIS case they're being reasonable. @RandomDamage
Thuis is exactly the systemd critisim you always hear. But if they don't do this, people like @RandomDamage also criticizes it.
I indeed also don't know what he expects they should do.
What they did made sense with what they knew at the time, now they know different and their response is "not our code, not our problem".
What they *should* do is not accept the response of the auth system if it generates any response but an unqualified authorization, whether through stderr or response code, but that would involve dealing with someone else's interface so they'll probably just rewrite it if they ever care.
@RandomDamage @rugk I don't think you understand how these two processes are interacting. And saying "what they should do is NOT..." is not answering the question "what should they do?" People write code that DOES something. They don't write code that does NOT do something. And I don't think you're contemplating what the code must DO, in order to NOT do the things you think it shouldn't do.
@paco Oh for Christ's sake
@paco Like that tmpfiles bug a while back "rm -rf / LOL" the real worry is what else in buried in all that C.
Do you need systemd, or is pkexec enough to exploit this?
@paco The 2000s are too shy and technologically awkward to call, I think they likely texted instead. It really is sad to see these still being a thing.
@Deveyus Yeah. If I still had my ICQ number, maybe I would have heard from them. :)
@paco why does your computer have more than two billion users?
I wasn't even aware that UIDs could go that high.
@ben Massive enterprises with tens of thousands of heterogenous systems, but a desire to have unified UIDs will use a lot more of the possible numbers than small companies with a handful of OSes and a handful of systems.
The 1970s called, they want to know why people use UIDs on systems without users.
A Mastodon instance for info/cyber security-minded people.