841–850 of 902 posts
Uses polkit. run0, which behaves like sudo, but works entirely differently and is not SUID. Run0 asks the services manager to create a shell or command under the target user’s ID, creating a new PTY, sending data back and forth from the originating TTY and the new PTY.
How hard would it be to create a program to send a signal to polkit "impersonating" run0 and obtains a root shell? :)
Earlier quoted context omitted.
This and many other discussions misses the point that most people that don't like systemd have with it. It can largely do everything it replaces, but differently, in some cases with improvements. Every year it increases its scope of 'problems' its solved. But the issue is it hasn't _ACTUALLY_ solved a problem for me in about a decade, its only introduced problems. Its replaced things that worked perfectly for me and…
> If it actively solved problems for the majority of users we wouldn't hate it so much It does and we don't. The only "we" who are "hating it so much" is a tiny vocal minority.
I wouldn't call the opposition tiny, although the vocal portion of any group tends to be the smallest. This would be my first online comment on it so I'm certainly part of the non-vocal group you ignore, that in my experience is significantly larger than the vocal side of group you dismiss.
Earlier quoted context omitted.
There's like 3 components involved in making setuid safe (the kernel, the dynamic loader, and your exec), and at least one of them wasn't doing its job correctly (the dynamic loader). IPC by definition involves a superset of these components. There's no reason to think that if you can't make a simple setuid binary safe, you can make IPC safe. IPC is an order of magnitude more involved. Specially because in order to g…
> There's like 3 components involved in making setuid safe (the kernel, the dynamic loader, and your exec), and at least one of them wasn't doing its job correctly (the dynamic loader). IPC by definition involves a superset of these components Incorrect, because nowhere in the IPC dance are these components exposed to the same untrusted environment as they are with sudo.
Earlier quoted context omitted.
you have the wrong view point. he just have a different opinion than you. he single handled managed to fool RH and all distros into turning Linux administration just like windows. systemctl list of services is so inspired by the atrocious windows' admin list of services (which have 3 fields supposed to describe the service, but they all just tell you the name again). it's no wonder his reward was a job at Microsoft.…
I continue to be baffled at this widespread belief that Poettering somehow hoodwinked every single major Linux distro into accepting a shit product with, idk, hypnosis or something. Is it not possible that systemd is simply better than the alternatives, and the distro owners are smart enough to notice that, instead of just wrapping themselves cultish mantras about The Unix Way and how anything which resembles a desig…
As if marketing alone could do that. Poettering does seem to be, to a casual observer, kind of a dick. Arrogant, dismissive of competing products... kind of like that other guy — also kind of a dick — who supposedly had that "reality distortion field" that hoodwinked all those poor saps into buying his phones.
There's no fucking way in hell you are able do that if the user base doesn't think the product is good. To those saying it, I always reply, "It may not be the product you want, but a shitload of people disagree with you, quite obviously."
I'm not personally a huge fan of the iPhone or systemd. But they are both clearly "the best" for the largest number of people. (And that is even clearer for systemd, as it doesn't cost hundreds or thousands of dollars more then the competing products.)
> Or in other words: the target command is invoked in an isolated exec context, freshly forked off PID 1, without inheriting any context from the client (well, admittedly, we do propagate $TERM, but that's an explicit exception, i.e. allowlist rather than denylist). I think in practice, this is going to be an endless source of problems, so much so that it won't be adopted. The usual use case of sudo is that you have…
run0 has already been exploited: https://twitter.com/hackerfantastic/status/17854955875146385... There will be plenty more where that came from. Yet another terrible idea and terrible implementation from Poettering.
I am really not looking forward to systemd taking over another part of the system with how unpolished and flaky their replacements usually are. Anyway, I have been using doas instead of sudo for a while on servers, it’s rock solid if you don’t need some of the more advanced features of sudo.
I honestly have no clue what you mean. You can take unit files, journald, timers, and all the other neat features from my cold, dead hands. I’m not going back to writing brittle shell scripts; systemd has made my life SO much easier.
Then stop doing that.
Earlier quoted context omitted.
run0 has already been exploited: https://twitter.com/hackerfantastic/status/17854955875146385... There will be plenty more where that came from. Yet another terrible idea and terrible implementation from Poettering.
The linked PoC requires that the attacker already has root so that it can disable the default ptrace protection.
So by design run0 does not do what sudo does. If I understand it correctly it has to stay a child of the daemon it's forked or does Linux provide an API to mangle the poor process table to change that since because according to POSIX the process would not part of the current session, or process group? How does this interact with (or break) shell job control since you can't forward SIGKILL. Does anything prevent the i…