_______ __ _______ | |
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----. | |
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --| | |
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____| | |
on Gopher (inofficial) | |
Visit Hacker News on the Web | |
COMMENT PAGE FOR: | |
Run0, a systemd based alternative to sudo, announced | |
isatty wrote 10 hours 53 min ago: | |
I wish systemd would die or just be just an init system. This whole | |
thread is people suggesting vague and non obvious solutions to things | |
that people already knew how to do with just linux utilities now with | |
some weird other binary. | |
bananapub wrote 8 hours 19 min ago: | |
what a bizarre point of view. | |
everything other than "being an init system" is a compile time option | |
in systemd, so your complaint is that ... other people are building | |
OSes and turning these things on? | |
which OS are you working on that provides all these convenient | |
features and large-scale integration of software with them, with code | |
that isn't in systemd? | |
chillfox wrote 10 hours 54 min ago: | |
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. | |
9dev wrote 7 hours 38 min ago: | |
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. | |
rmbyrro wrote 13 hours 41 min ago: | |
Why use a short-form message social network to publish a blog post? | |
hello_computer wrote 14 hours 1 min ago: | |
fix pulseaudio and then we can talk. | |
yencabulator wrote 2 hours 56 min ago: | |
Someone else did it and the better pulseaudio is called pipewire. | |
Can't wait for that to happen to all the parts of systemd too, one | |
day. | |
praseodym wrote 15 hours 36 min ago: | |
There is also a write of sudo in Rust, which works more akin to the | |
traditional sudo but memory-safe and with fewer bugs: [1] Source code: | |
[2] And if you are running Debian 13 (trixie) or later, or Ubuntu 24.04 | |
(Noble Numbat) or later, you can already install it using `apt install | |
sudo-rs`. | |
[1]: https://www.memorysafety.org/blog/sudo-first-stable-release/ | |
[2]: https://github.com/memorysafety/sudo-rs | |
Netch wrote 15 hours 48 min ago: | |
A similar idea was tested in an experimental BSD clone in Berkeley in | |
mid-1980s. (Great sorry I havenʼt kept link to the description, so | |
rephrase with my own words. Maybe this was in the McKusickʼs book?) | |
No suid or sgid was allowed. A daemon started from init and listening | |
on a socket listened for connections, checked permissions and run the | |
specified binary with requested permissions. A caller had to interact | |
with the started program using pipes. | |
It seems the complexity of passing all to pipes was why the approach | |
was rejected. Instead, the checking of inherited environment was | |
strengthened. "Everything new is well forgotten old." | |
LNK_ wrote 3 hours 59 min ago: | |
Listen socket (especially network socket), accept remote commands, | |
and execute them as root. | |
Sounds like a nice tool:) | |
lyu07282 wrote 11 hours 42 min ago: | |
44 years and ~20 local privilege escalation vulnerabilities later... | |
constantcrying wrote 17 hours 40 min ago: | |
>But enough about all that security blabla. The tool is also a lot more | |
fun to use than sudo. For example, by default it will tint your | |
terminal background in a reddish tone while you are operating with | |
elevated privileges. That is supposed to act as a friendly reminder | |
that you haven't given up the privileges yet, and marks the output of | |
all commands that ran with privileges appropriately. | |
WHAT AM I READING?? Why can't the systemd developers just be normal? | |
I also suspect that this will interact terribly with anyone who uses a | |
certain kind of terminal theme. Do they not know that you can have | |
these "nice to have" features, off by default, so that anyone who wants | |
can enable them and anyone else is never bothered by them? | |
nottorp wrote 18 hours 41 min ago: | |
Yeah, Pottering's quest to overcomplicate Linux continues... | |
PublicSimple wrote 11 hours 30 min ago: | |
Itâs fitting heâs now at Microsoft. Thatâs the MS way. | |
nottorp wrote 10 hours 53 min ago: | |
You don't say... reminds me of the Nokia dude... Elop was his name? | |
jimrandomh wrote 18 hours 52 min ago: | |
> 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 a normal shell command, making use of the environment for | |
context in all the ways that shell commands do, but it doesn't have all | |
the permissions it needs, so you add "sudo" as an adverb. | |
Sometimes it makes use of environment variables. Sometimes stdin or | |
stdout is redirected to a file, or to something more exotic than a | |
file. Sometimes that means it runs inside of a chroot, or a Docker | |
container. Sometimes you care about which process group it runs in. | |
And sometimes the thing you're running is a complicated shell script or | |
shell-script-like object, eg "sudo make install". In this case, you | |
don't really know what its dependencies are. In fact this is a common | |
enough case that, if run0 becomes widespread, I expect it'll have a | |
flag or a set of flags that make it act exactly like sudo, and I expect | |
people to wind up learning that they should always give run0 those | |
flags. | |
And I'm kind of worried that when this breaks stuff, the systemd | |
project is going to push forward with some plan to get rid of sudo, and | |
not gracefully accept the feedback that this is breaking things. I'm | |
particularly worried about this because of the whole saga of | |
KillUsersProcesses breaking nohup and screen, which to my knowledge is | |
still broken many years later. | |
sigil wrote 10 hours 3 min ago: | |
run0 has already been exploited: [1] There will be plenty more where | |
that came from. Yet another terrible idea and terrible implementation | |
from Poettering. | |
[1]: https://twitter.com/hackerfantastic/status/17854955875146385... | |
mananaysiempre wrote 6 hours 48 min ago: | |
To be fair, this is not at all Poetteringâs idea. There is, for | |
example, precedent in the form of s6-sudo[1], a utility from the s6 | |
service supervisor, itself very much an anti-systemd project | |
(except I believe it predates systemd?..). | |
And honestly Iâd be okay with a suidless Unix. For example, as | |
best as I can tell, the only reason the kernel needs to know what | |
executable formats even areâbeyond the bare minimum needed to | |
load PID 1âis s[ug]id binaries. | |
[1]: https://skarnet.org/software/s6/s6-sudo.html | |
jimrandomh wrote 7 hours 13 min ago: | |
I wouldn't worry too much about that. It's a tricky piece of | |
security-critical software, receiving its first round of outside | |
auditing; of course it has vulnerabilities. Sudo does have the | |
advantage of being much more battle-tested, but that will even out | |
with time; what will matter is how secure it is two years from now. | |
lofenfew wrote 9 hours 28 min ago: | |
What's the difference between this and ptracing the bash session | |
that you run sudo under? | |
nickelpro wrote 1 hour 39 min ago: | |
None, it's a nonsense "hack" | |
mahkoh wrote 9 hours 29 min ago: | |
The linked PoC requires that the attacker already has root so that | |
it can disable the default ptrace protection. | |
sfink wrote 9 hours 44 min ago: | |
Huh. I'm not at all a fan of how Poettering operates, but it's | |
neither the ideas nor the implementation where I'd fault him. Well, | |
it depends on what you mean by implementation, I guess; I'm talking | |
about the core "how does it do its thing", not the interface by | |
which you use it. | |
I think Poettering has great ideas and great implementation. It's | |
the execution and interface that are often terrible. If the square | |
peg doesn't fit in the round hole, then he'll always say that the | |
peg is perfect and the world just needs to chisel out the corners | |
of the hole. | |
1oooqooq wrote 9 hours 31 min ago: | |
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. | |
but again, he's good in all three aspects. you just disagree on | |
building the torment Nexus that is putting Linux in the "standard | |
certification" target for sysadmins. | |
Analemma_ wrote 6 hours 48 min ago: | |
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 design used in | |
Windows is bad by definition? Or could that not possibly be it | |
and he must've used mind control magic. | |
superpatosainz wrote 7 hours 43 min ago: | |
It's inspired by Apple's launchd. | |
KWxIUElW8Xt0tD9 wrote 11 hours 48 min ago: | |
One binary to rule them all, one binary to find them, one binary to | |
bring them all and in the darkness bind them; in the Land of Lennart | |
where the shadows lie. Bwaahahaha. | |
Aerbil313 wrote 3 hours 14 min ago: | |
This gave me a genuine chuckle. Clever humor, thank you. | |
bayindirh wrote 13 hours 56 min ago: | |
> And I'm kind of worried that when this breaks stuff, the systemd | |
project is going to push forward with some plan to get rid of sudo, | |
and not gracefully accept the feedback that this is breaking things. | |
Given Lennart already declared SUID concept as âbadâ, I think | |
this is the game plan all along. | |
Systemd: Do all the things, but not very well, and donât listen to | |
anyone. | |
lyu07282 wrote 12 hours 47 min ago: | |
I agree with Lennart so I'm curious what the argument is against | |
the notion that SUID was a bad idea and we should move away from it | |
in Linux? | |
jimrandomh wrote 6 hours 57 min ago: | |
Setuid is a mechanism where you take a program, and mark it so it | |
always runs as root (or some other user, but in this case root). | |
The idea is that an unprivileged user can run a setuid program, | |
and the program itself decides what privileges to allow. | |
The problem is that the user controls the program's view of the | |
filesystem, environment variables, and other attributes, and this | |
is an attack surface that can be used to trick it into loading | |
and running code provided by the unprivileged user, which runs as | |
root. For example, ordinary programs have a preamble inserted by | |
the compiler where they load a programming-language runtime, | |
usually from somewhere like /usr/lib; but a setuid program can't | |
safely do this, because the user could use a chroot to replace | |
/usr/lib with something different. | |
In practice, this means that writing a setuid program correctly | |
is exceptionally difficult and error prone, can only be done in | |
C, and imposes security requirements on the compiler | |
flags/makefiles rather than the source code, which creates a | |
large risk of distro- or compiler-specific vulnerabilities. In | |
practice, sudo is the only program people allow to use the setuid | |
mechanism, and sudo is a unique and dangerous snowflake. | |
lucideer wrote 9 hours 47 min ago: | |
The problem with this line of thinking is it gives automatic | |
carte blanche to anyone pointing out problems to implement | |
"solutions" to those problems with little interrogation of | |
whether those solutions are actually better. | |
SUID, like any system, is flawed. Most of those flaws are | |
balanced trade-offs; if you're addressing one you need to be | |
aware of the severity of any counter-problems you're inevitably | |
introducing. | |
Lennart is well known for criticising existing systems while | |
simultaneously ignoring & dismissing criticism of the proposed | |
solutions - you need to be able to weigh up both sides in a | |
balanced way. Lennart demonstrably isn't. | |
bayindirh wrote 11 hours 9 min ago: | |
SUID mechanism doesnât always âelevate to rootâ. Itâ… | |
mechanism to ârun as another userâ and with SGID allows great | |
flexibility in user permission management. You can allow all | |
kinds of (responsible) user switch tricks for multi-admin servers | |
and multi-user systems. | |
Focusing all of this to sudo and framing SUID as âjust | |
implemented to enable sudoâ is not painting the correct | |
picture. | |
Moreover, removing SUID breaks tons of mechanisms and scenarios. | |
Security of sudo can be debated, but evolving current sudo to a | |
better state step by step is miles better than banishing and | |
rebuilding it and making it dependent on systemd + polkit. | |
systemd already breaks tons of UNIX conventions and way more | |
complicated than it should be. | |
When you think, it sounds like âconqueringâ another part of | |
user space mixed with NIH (and we know the best), and making | |
systemd more entrenched. systemd is already a pretty large | |
surface area to attack to begin with. | |
XZ back door reached SSHd over libaystemd. Do we need another | |
âintegrated targetâ to attack in Linux? | |
crabbone wrote 9 hours 36 min ago: | |
All these ideas that tie permissions to a file completely fail | |
when files need to be accessed either over network, or inside a | |
container. | |
I can see how the original authors didn't consider these cases, | |
because they simply weren't there yet... but knowing what we | |
know today: SUID is an awful idea. | |
bayindirh wrote 6 hours 44 min ago: | |
Sorry for my ignorance, but whatâs a scenario that you run | |
a SUID/GUID binary from a network or a container? | |
If you access and run, itâs SSH or similar, so it works on | |
the system scope. If itâs a container built correctly, it | |
has its own users and isolation already, so it shouldnât be | |
able to fire any binary on your âbaseâ system, and any | |
effect is already in the container scope. | |
I have never had the need to SUID/GUID a non executable, and | |
didnât need to trigger something on the system inside a | |
container in the last ~20 years. | |
crabbone wrote 3 hours 36 min ago: | |
> but whatâs a scenario that you run a SUID/GUID binary | |
from a network or a container? | |
A lot of publicly available container images require | |
elevated permissions to simply function, not for anything | |
extraordinary. So, the user in container needs to be a | |
superuser. It's often even not to perform the program's | |
main function, but because various ordinary things in Linux | |
require elevated permissions. | |
> container built correctly | |
That's a spherical horse in vacuum. If you write code s.t. | |
there aren't any errors, you don't need to do error | |
handling, right? You don't get to choose how containers | |
are built. You need to deal with all possibilities of how | |
containers can be built. | |
Network filesystem? -- /usr/shared, /usr/opt and | |
/usr/local? That's by design... very typical for cluster | |
management software to mount these from NAS. It's also | |
very not typical to keep these as "only text files". | |
Pretty sure a lot of Google's stuff installs automatically | |
into /usr/shared. I think even Go compiler and other infra | |
at some point was being installed there by default. | |
Finally: the same argument as with containers. You, for | |
some reason, are trying to fantasize the world where | |
problems don't exist because you chose the world w/o | |
problems. But this isn't the real world. It's a fantasy. | |
In real world, with or without reason, programmers and | |
other computer users will do what's possible, not what you | |
want them to do. | |
datadrivenangel wrote 12 hours 38 min ago: | |
SUID has flaws, but it's not clear that there are any more | |
convenient alternatives? | |
1oooqooq wrote 9 hours 24 min ago: | |
you missed the memo. it's dbus. (wish i could end with /s) | |
throw0101b wrote 14 hours 19 min ago: | |
> And I'm kind of worried that when this breaks stuff, the systemd | |
project is going to push forward with some plan to get rid of sudo, | |
and not gracefully accept the feedback that this is breaking things. | |
See for example perhaps, "systemd can't handle the process previlege | |
that belongs to user name starts with number, such as 0day": | |
* [1] Never mind that POSIX allows it: | |
* [2] * [2] > I'm particularly worried about this because of the | |
whole saga of KillUsersProcesses breaking nohup and screen, which to | |
my knowledge is still broken many years later. | |
For anyone curious, see "Systemd v230 kills background processes | |
after user logs out, breaks screen, tmux" from 2016: | |
* | |
[1]: https://github.com/systemd/systemd/issues/6237 | |
[2]: https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd... | |
[3]: https://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd... | |
[4]: https://news.ycombinator.com/item?id=11782364 | |
keepamovin wrote 16 hours 53 min ago: | |
Yeah we had to explicitly set that to No and enable linger to let | |
pulseaudio keep running for users so they can continue to stream | |
sound from their remote browsers in BrowserBox/CloudTabs. Ie at: [1] | |
Your comment was really well expressed btw. Made your thoughts and | |
emotions very clear about this. Inspiring communication skill! :) | |
[1]: https://puter.com/app/cloudtabs-browserbox | |
lyu07282 wrote 17 hours 50 min ago: | |
I think what is perhaps something to consider is how much of an | |
attack surface sudo is and how unaware people are of the fact. Many | |
people think they can configure sudo to be safe to use for | |
unprivileged users, by only allowing specific things to run with it. | |
But they don't realize all the ways it can be abused for privilege | |
escalation. Getting rid of all that configuration removes that false | |
sense of security, which is a good thing, it has been a huge footgun | |
in Linux for decades. Some incompatibility is price well worth paying | |
for that imho | |
lupusreal wrote 16 hours 49 min ago: | |
I think these problems are basically negligible because the amount | |
of people trying to "configure sudo to be safe to use for | |
unprivileged users, by only allowing specific things to run with | |
it" is negligible. Virtually all users of sudo are using it on | |
their own computer which they are the sole user and ultimately the | |
administrator of. Even in corporate contexts where the company | |
owns the machine instead of the user, I've only ever seen cases | |
where the use of sudo is unrestricted albeit logged. Where are | |
these organizations where developers or syaadmins are allowed to | |
use sudo but only with white listed commands? I don't doubt that | |
some people are doing this, I just think it's not common. | |
Replacing the whole of sudo with some weird new thing to better | |
support a niche usecase seems disconnected from reality to me. | |
otabdeveloper4 wrote 7 hours 15 min ago: | |
'systemd-run except with privilege escalation' is a thing I | |
wished for for a long time, needed in production. | |
Glad they finally made it, too bad it took them so long. (To be | |
honest, it feels like it should have just been part of | |
systemd-run in the first place.) | |
crabbone wrote 9 hours 31 min ago: | |
> Virtually all users of sudo are using it on their own computer | |
Nope. If I had to guess, it's in containers, like Docker. And | |
those run in lots of places, and often in places with easy access | |
to company's cloud account, credit card info etc. | |
lyu07282 wrote 12 hours 59 min ago: | |
Its a common finding during pentests, but that's just | |
unconvincing anecdote vs. anecdote. Another argument, besides | |
misconfiguration, is the reduced attack surface by removing the | |
huge complexity of sudo entirely. If your argument is basically | |
that its fine because nobody is using the complexity of sudo, | |
then I don't quite understand what your objection is to removing | |
that complexity. You might need to manually restore some | |
env-vars, whats the big deal? | |
But I suspect this would just turn into a "doing things | |
differently is bad because its doing things differently" | |
argument, its not a very useful conversation to have. | |
Hendrikto wrote 15 hours 2 min ago: | |
> Virtually all users of sudo are using it on their own computer | |
which they are the sole user and ultimately the administrator of. | |
This is not the case at all. The vast vast majority of Linux | |
installs are on servers. | |
tomxor wrote 12 hours 17 min ago: | |
That's not what parent means. They are arguing it's not | |
generally used to delegate partial root access to unprivileged | |
users, i.e by adding narrow sudoers rules to allow "some" | |
specific things to be run as root for some users who don't have | |
full root access otherwise. | |
I tend to agree that 99% or use cases are just a convenient way | |
to gain full root for users with full root access. Configuring | |
sudoers for the former use case has long known to be a bit | |
dangerous, i.e it's easy to get it wrong and create privilege | |
escalation holes. | |
troyvit wrote 12 hours 54 min ago: | |
Then I propose letting systemd hijack sudo's usefulness only on | |
server installs. | |
sapphire_tomb wrote 16 hours 34 min ago: | |
My last job was at a UK bank. All our *nix systems were | |
configured with a specific whitelist of commands that could be | |
run via sudo. | |
We found this an enormous pain in the arse when the powers that | |
be decided to deploy ansible everywhere, and found that none of | |
its "become" methods would work if sudo was set up like that. | |
fullstop wrote 12 hours 5 min ago: | |
I had a job once which had a sudo whitelist, but vi was | |
included. !sh and you had root. | |
acdha wrote 9 hours 17 min ago: | |
I also liked one where you could `sudo rpm -i` | |
TheRealDunkirk wrote 11 hours 15 min ago: | |
Classic case of #CorporateIT applying white paper "rules" and | |
not understanding what they're doing. If I had a nickel... | |
fullstop wrote 8 hours 38 min ago: | |
Exactly, forms were filled in and boxes were checked off. | |
jeremyjh wrote 15 hours 40 min ago: | |
Those environments could continue to use sudo. I'm sure Red Hat | |
will support it until long after we all dead. | |
WesolyKubeczek wrote 16 hours 5 min ago: | |
Not even using "su" as become_method? Granted, it would require | |
the root's password, so it's another tradeoff, but... | |
yorwba wrote 18 hours 26 min ago: | |
I don't know what your sudo does, but mine requires the | |
--preserve-env flag if you want the new process to have access to all | |
your environment variables. | |
The thing you're saying is going to be an endless source of problems | |
should already be an endless source of problems! (And I think I've | |
been briefly confused by some missing environment variable once or | |
twice so far.) | |
crabbone wrote 9 hours 33 min ago: | |
Even without the flag, sudo preserves a bunch of stuff. And it's | |
not even consistent. Some implementations preserve locale setting, | |
while others don't for example. | |
0x457 wrote 5 hours 38 min ago: | |
It depends on what options sudo us built with. Notably | |
`--disable-env-reset` option. | |
mid-kid wrote 18 hours 7 min ago: | |
It depends on whether sudo was compiled with --disable-env-reset or | |
not, it's on by default[1]. | |
Also some variables are inherited regardless (e.g. DISPLAY, TERM), | |
and some useful ones (e.g. HOME) are initialized by sudo, but I | |
can't tell where that's done. | |
[1] | |
[1]: https://github.com/sudo-project/sudo/blob/ef52db46f9b375d7... | |
theshrike79 wrote 18 hours 58 min ago: | |
I think we're entering a point where GNU/Linux should be called | |
Systemd/Linux | |
mrighele wrote 17 hours 22 min ago: | |
That was the plan (by Redhat) all along, to have better control of | |
the platform. | |
Spivak wrote 13 hours 22 min ago: | |
To what end? It seems Redhat made a thing that solved a lot of | |
their problems as distro maintainers and then made it OSS. This | |
"control" doesn't really buy them anything. | |
mvelbaum wrote 19 hours 5 min ago: | |
Maybe this isn't a good idea? | |
[1]: https://twitter.com/hackerfantastic/status/1785495587514638559 | |
YtvwlD wrote 18 hours 10 min ago: | |
If this is the only bug, then this is easily solvable: create the pty | |
in the daemon. | |
j16sdiz wrote 19 hours 20 min ago: | |
Oh, great. | |
Adding another moving parts via IPC to essential system tool. | |
Sure this would make recovery/rescue scenario more "fun". | |
ccorcos wrote 19 hours 37 min ago: | |
Can someone explain what this is / how it works to someone who has done | |
a considerable amount of programming but lacks this kind of operating | |
system level knowledge? | |
I was under the impression that âsudoâ was baked into the entire | |
system. Like âcdâ or âpsâ. How exactly can you just swap o… | |
sudo? Does that involve swapping out chmod as well? | |
michaelt wrote 13 hours 55 min ago: | |
> I was under the impression that âsudoâ was baked into the | |
entire system. | |
There's a capability baked into the entire system named 'setuid' | |
which allows certain binaries run by a user to access things as if | |
they were root. | |
For example, when a user changes their password using 'passwd' that | |
executable gets special write access to the file containing hashes of | |
all users' passwords. The system's security relies on passwd being | |
coded carefully enough that it won't let one user change another | |
user's password, no matter what input they give it. | |
sudo is "just" a setuid binary, which checks if the user is allowed | |
to run things as root and if so uses its power to run them. It can be | |
replaced. | |
There are a bunch of design implications resulting from the way | |
setuid works - for example, the operating system has a special | |
setting so if you plug in a USB drive containing a setuid binary, the | |
setuid bit on it gets ignored. So you can't make a special version of | |
sudo at home which doesn't check permissions, then take it to the | |
school computer lab and have it work there. | |
cesarb wrote 11 hours 59 min ago: | |
> There's a capability baked into the entire system named 'setuid' | |
which allows certain binaries run by a user to access things as if | |
they were root. | |
It's actually "to access things as if they were the owner of the | |
binary" (which usually is root, but that's not required). | |
The problem with that, is that other than the uid, the program | |
inherits everything like a normal program. Environment variables, | |
current directory, open file descriptors, and so on. If the program | |
(and the dynamic linker it uses, and any library it uses including | |
the C standard library) is not very careful, it can be tricked | |
through these inherited things to do unexpected actions while being | |
able to access things as if they were root (or whoever the owner of | |
the binary is). For instance, some environment variables tell the | |
dynamic linker to load extra libraries, or to change from where it | |
loads libraries; these have to be ignored when running as a setuid | |
process. | |
keeperofdakeys wrote 19 hours 6 min ago: | |
Any linux process can run with elevated privileges (ie: as root) by | |
setting a specific permission bit - [1] . This is used for many | |
things like ping and sudo. | |
Instead Run0 is using systemd to elevate privileges. | |
There is a lot that could be said, but suffice to say you can have | |
both sudo and Run0 installed. So even if a Distro ships Run0 by | |
default, you can always manually install sudo. | |
[1]: https://en.wikipedia.org/wiki/Setuid | |
stouset wrote 19 hours 18 min ago: | |
> I was under the impression that âsudoâ was baked into the | |
entire system. Like âcdâ or âpsâ. | |
Neither of these are âbaked into the entire systemâ for any | |
meaningful sense of the word. `cd` is just a shell builtin and is | |
casually reimplemented in every single shell. Itâs just environment | |
state within your session. `ps` is just a binary that (on Linux) | |
parses stuff in /proc. | |
None of it is magic. Neither is sudo. Itâs just a binary like any | |
other (though in sudoâs case, itâs setups, which is how it can | |
cross the permissions boundary). | |
anon291 wrote 19 hours 26 min ago: | |
Sudo is a program that: | |
1. Parses the sudoers file to check if the current user can run the | |
command provided. | |
2. If so, authenticates the user using PAM. | |
3. If both those pass, sets the user id to root and runs the program. | |
There is nothing special about it. All steps can be done by any | |
program. In fact sudo is usually not even an installed by default | |
package in many systems. | |
The only seeming magic bit is part 3, where the program sets it's | |
user id to root. Obviously if any program could do this... That'd be | |
unsafe. | |
However, unix systems allow any executable file to have their flags | |
changed to include the setuid bit which causes the file to execute | |
with privileges of the files owner. You'll notice that the sudo | |
binary has this bit set and it's owned by root, which explains now | |
the entire process. | |
Galanwe wrote 18 hours 54 min ago: | |
Just to highlight some of the complexities of `sudo` to complement | |
your helicopter view: | |
- Sudo can use PAM, or any other means, depending on NSS (local, | |
ldap, through PAM, etc) | |
- Sudo can use a sudoers file, directory, or even LDAP fields to | |
resolve accesses. | |
- Sudo can temporarily cache and forward authentication to avoid | |
constantly retyping passwords | |
- Sudo can elevate you depending on your group, user, or even a | |
glob of the command you want to type | |
- Sudo can log and report the executed commands | |
- Sudo can import none, part or all of your environment to run its | |
command | |
- Etc | |
Sudo is very complex | |
cookiengineer wrote 17 hours 57 min ago: | |
The setuid part is where things get exploitable. Pretty much any | |
exploit to date was abusing a library's assumption about what to | |
sideload or what to persist after it got root rights for whatever | |
reason. | |
"Good distro maintainers" (e.g. Arch Linux) try to minimize the | |
attack surface by modifying their packages to use the | |
capabilities flags instead (e.g. the net cap flag for ping | |
binary). | |
"Bad distro maintainers" blame the end user for their own | |
responsibility for letting this happen. They could have just | |
uninstalled the program, right? | |
Well, I disagree. SystemD's new approach is that they try to | |
reuse the seccomp sandboxes they've introduced for a while now, | |
where root rights-given processes can even be executed in a | |
chroot, with a fake /etc/passwd file, with fake users, with fake | |
/dev ices etc. | |
As SystemD as the process #1 always has to be executed as root, I | |
think it's a good thing that they try to offer a sandboxed | |
alternative. Polkit is just so damn ugly with all their hacky | |
subscriptions and policy files. If you disagree with me, I | |
recommend you to learn more about privilege escalation exploits | |
on POSIX systems, and how PAM, Polkit and pretty much any auth | |
framework always said it's the users fault. | |
LD_PRELOAD auth bypasses are now more than 18 years old, and the | |
CVE still works on enterprise-grade linux distributions. It | |
literally was the reason muslc was created as an alternative to | |
glibc. And that's older than a decade now. | |
Check out [1] (or the Windows NT equivalent LOLbins) if you wanna | |
know how many binaries there are as an attack surface. | |
[1]: https://gtfobins.github.io | |
dijit wrote 14 hours 18 min ago: | |
Honestly though, elevating privilege is inherently the | |
exploitable part of any program that attempts to cover this | |
space. | |
I would guess you are arguing in a reduction in complexity, | |
which is semi-ironic as run0 is including polkit (and thus: an | |
entire JS interpreter) among other things; while at the same | |
time doas/sudo-rs exist as simpler implementations. | |
AFAIK, lots of the bloat of sudo is preventing a lot of the | |
attacks you mention though, but I seriously doubt any privilege | |
escalation system doesn't have any weak parts that need heavy | |
scrutiny. | |
Jonnax wrote 19 hours 29 min ago: | |
Sudo isn't baked into the system. It's an application. [1] Did you | |
read the thread linked? | |
[1]: https://www.sudo.ws/ | |
ErikBjare wrote 19 hours 30 min ago: | |
sudo is just another program, it's not "baked in" as such. It just | |
ships with many (not all) distros. I remember having to install it | |
from repos in the past on a new system: | |
[1]: https://github.com/sudo-project/sudo | |
ErikBjare wrote 8 hours 26 min ago: | |
Reminds me of an assignment I had at uni to implement sudo in C. | |
You get elevated permissions using the setuid bit, and can verify | |
the password of $USER against /etc/passwd. | |
tommica wrote 19 hours 33 min ago: | |
Pretty sure `sudo` is an application that you can remove, it just | |
comes pre-installed in many distros. | |
gattilorenz wrote 19 hours 27 min ago: | |
Not only that, but it became commonly included only about 20 years | |
ago. | |
I spent my first years with Linux calling âsuâ instead. | |
I still run some very old distribution (e.g. RedHat 6.2) on a | |
Pentium 1 laptop, and I downloaded the source of sudo and compiled | |
it on it, since the sources were not even included in the extended | |
CD set. | |
apexalpha wrote 19 hours 33 min ago: | |
sudo, and even cd and ps you mention are simply binaries that come | |
shipped with your distro / OS. | |
They, like explorer.exe on Windows, are an essential part of that OS | |
with special privileges and roles but they are not part of the | |
kernel, they are still simply programs. It is not developed by the | |
people who develop the Linux kernel. | |
There are other Sudo alternatives such as DoAs already. | |
csande17 wrote 19 hours 23 min ago: | |
While some systems include a "cd" binary, it's basically useless | |
since it just changes its own working directory and then exits. | |
Instead, "cd" commands are generally parsed and executed by your | |
shell (/bin/sh or similar) directly so that the shell's working | |
directory gets changed and you can run subsequent commands in the | |
new location. | |
"ps" on the other hand is indeed just a normal program. Usually it | |
reads files in /proc to figure out which processes are running. | |
thayne wrote 20 hours 3 min ago: | |
First of all, I like the idea. But I have questions. | |
What does logging look like for this? | |
I don't think it would be too difficult to log commands run with | |
polkit, but is there an equivalent of sudo I/O logs? My guess is there | |
isn't now, but to fully replace sudo it will probably need a way to | |
record everything on the ptty it creates. | |
What environment variables does it forward by default? From the man | |
page it sounds like SHELL is. What about TERM? Any others? What | |
environment variables are set? What is PATH set to? | |
How are signals handled? Will a signal sent to the run0 process be | |
propagated to the priveleged process? | |
What about sudoedit? How would I achieve similar functionality with | |
run0? | |
cl3misch wrote 19 hours 40 min ago: | |
From the post: | |
> well, admittedly, we do propagate $TERM, but that's an explicit | |
exception, i.e. allowlist rather than denylist | |
DeathArrow wrote 20 hours 9 min ago: | |
Someday systemd will going to replace Linux entirely. | |
ykonstant wrote 20 hours 19 min ago: | |
Is there a way to read this sequence of messages as a coherent whole in | |
the correct order? | |
emmelaich wrote 22 hours 9 min ago: | |
This is great! | |
There was (is?) a program developed by some debian developers that did | |
a similar thing way back, but I can't remember it. | |
Anyone? | |
[edit - [1] is probably what I'm thinking of] | |
[1]: https://www.chiark.greenend.org.uk/~ian/userv/ | |
yonatan8070 wrote 22 hours 4 min ago: | |
I know of doas[1], but that appears to be an OpenBSD thing. Maybe | |
Debian folks ported it? | |
[1]: https://wiki.archlinux.org/title/Doas | |
rfmoz wrote 20 hours 46 min ago: | |
hopefully | |
pkulak wrote 22 hours 36 min ago: | |
But can I symlink sudo instead of run0? There are so many scripts that | |
assume sudo, not to mention my own fingers. | |
orzi wrote 23 hours 9 min ago: | |
Mother: We already have sudo at home | |
HN: But, Mom! | |
udev4096 wrote 1 day ago: | |
Just a side note: sudo is largely maintained by just one dude | |
[1]: https://github.com/sudo-project/sudo/graphs/contributors | |
aixpert wrote 19 hours 33 min ago: | |
Don't worry I offered him help. I recently helped xz library too | |
m463 wrote 19 hours 44 min ago: | |
also worth mentioning: Lennart Poettering | |
"Poettering is known for having controversial technical and | |
architectural positions regarding the Linux ecosystem" | |
[1]: https://en.wikipedia.org/wiki/Lennart_Poettering | |
jeltz wrote 14 hours 21 min ago: | |
And another of the systemd devs, Kay Sievers, was banned from | |
contributing to the Linux kernel due to his bad attitude and | |
unwillingness to collaborate. | |
Poettering and Sievers are skilled devs with huge egos. | |
merpkz wrote 18 hours 1 min ago: | |
Is this guy still hated and receiving death threats? Also didn't | |
knew he is working for Microsoft now, that's an interesting career | |
change. | |
aerique wrote 14 hours 33 min ago: | |
And explains so much! | |
vaylian wrote 19 hours 11 min ago: | |
His positions are mostly controversial because he challenges the | |
way things have been done for a long time. Whenever he presents | |
some new idea/architecture my first reaction is often confusion. | |
Why would he change something that has worked so well for such a | |
long time? But then I take the time to read up on the reasoning | |
behind his ideas and then things start to make sense. Even when | |
something isn't exactly broken, there is still room for better | |
solutions. | |
lupusreal wrote 16 hours 44 min ago: | |
He's controversial because numerous times his ego has so severely | |
clouded his judgemental that he refuses to see egregious bugs in | |
his programs for what they are. Just one example: [1] The | |
"people hate him because he makes new stuff" narrative is just | |
more ego-protecting cope. Many developers of other new systems | |
are widely respected and appreciated because their stuff works | |
and they stay humble. Wireguard and Pipewire devs don't get hate | |
poured on them in HN discussions because their shit works, solves | |
problems people have, and because they know how to deal with | |
people. | |
[1]: https://github.com/systemd/systemd/issues/6237#issuecomm... | |
magicalhippo wrote 15 hours 52 min ago: | |
Or in Linus Torvalds' words[1]: | |
It does become a problem when you have a system service | |
developer who | |
thinks the universe revolves around him, and nobody else | |
matters, and | |
people sending him bug-reports are annoyances that should be | |
ignored | |
rather than acknowledged and fixed. At that point, it's a | |
problem. | |
[1] | |
[1]: https://lkml.org/lkml/2014/4/2/580 | |
filmor wrote 7 hours 15 min ago: | |
This is about Kay Sievers, not Lennart Poettering. | |
calvinmorrison wrote 13 hours 24 min ago: | |
But even then, system service developers don't try to 'own | |
the whole world' so to speak and so they do need to play | |
nicely with others. Mr. Poopering philosophy is the minute a | |
dependencies maintainer becomes a thorn in his side - he | |
absorbs that project into systemd. The distribution packagers | |
follow like starving dogs on a hunt | |
j0057 wrote 10 hours 57 min ago: | |
> Mr. Poopering | |
This is childish and petty, I suggest you delete your | |
account. | |
calvinmorrison wrote 10 hours 50 min ago: | |
No thanks! | |
etc-hosts wrote 10 hours 52 min ago: | |
You can't delete your HN account. | |
j0057 wrote 8 hours 37 min ago: | |
Interesting! IANAL, but I think this should be basic | |
functionality, ever since the recent-ish European and | |
Californian privacy regulations. Although I think a | |
quick e-mail to [email protected] would suffice. | |
Aerbil313 wrote 3 hours 8 min ago: | |
Would it really? Asking cause genuinely curious, | |
literally the only online forum I can't remove my | |
past public information from is HN. | |
NekkoDroid wrote 16 hours 17 min ago: | |
> Just one example: [1] ... | |
1. He gave a clear reason why it is how it is | |
2. He realizes it is/might be frustrating | |
3. even `adduser` will not allow it by default | |
4. The issue that it still runs the unit even with config | |
errors has been addressed: [2] (~2 weeks after the issue was | |
opened) | |
[1]: https://github.com/systemd/systemd/issues/6237#issueco... | |
[2]: https://github.com/systemd/systemd/commit/bb28e68477a3... | |
lupusreal wrote 12 hours 33 min ago: | |
His reason, although clear, is also plainly wrong. Such | |
usernames although bizarre may be encountered by SystemD so | |
it shouldn't break when it sees them. Computer programs, | |
particularly important ones, should be conservative in what | |
they emit and liberal with what they accept and that means | |
not breaking when they encounter weird but technically | |
permissible usernames. His response should have been "Golly, | |
that's a weird username, I didn't think that was possible" | |
and then fix the bug. | |
magicalhippo wrote 7 hours 24 min ago: | |
Alternatively, if, like he says in the comments of that | |
bug, he really means that SystemD shouldn't support systems | |
that allow such usernames, then he should ensure SystemD | |
won't run on such systems. | |
Silently doing the wrong thing is not a good thing, | |
especially when "doing the wrong thing" is running stuff as | |
root that wasn't supposed to run as root. | |
alserio wrote 8 hours 31 min ago: | |
Disclaimer: I know nothing about the particular bug. | |
Postel's Law has its tradeoffs, and its fuzzy lines are a | |
nice place for security issues to arise. | |
lupusreal wrote 6 hours 14 min ago: | |
For sure, there are limits. In this particular case, | |
maybe we say that SystemD shouldn't support weird | |
usernames beginning with numbers, but the other half of | |
the law should still apply. The conservative emission | |
would be logging an error message, not running that unit | |
file as root. | |
4star3star wrote 10 hours 1 min ago: | |
There is a certain personality type that likes to reimagine | |
that their original thinking was not flawed, even when | |
presented with a detail that they did not incorporate into | |
their original thinking. If the detail had been in their | |
awareness from the start, they would have arrived at a | |
different position, but they are bound to a strict sense of | |
linearity for reasons inexplicable to me except for ego | |
protection. | |
throw0101b wrote 13 hours 11 min ago: | |
> 3. even `adduser` will not allow it by default | |
5. useradd does allow it (as noted in a comment). 6. Local | |
users, and the utilities that create them, are not the only | |
source, there things like LDAP and AD. | |
7. POSIX allows it: | |
* | |
[1]: https://github.com/systemd/systemd/issues/6237#issue... | |
cduzz wrote 18 hours 59 min ago: | |
There have been lots of suggestions for how to improve linux / | |
unix for a very long time. | |
The first great war I remember, and I'm sure there were more | |
before I was around, was DJB vs everyone. For the most part, I | |
think his designs, "weird" as they were / are, are still better | |
than almost every crackpot variation of them that's come since. | |
karma_pharmer wrote 3 hours 17 min ago: | |
Dude you cannot compare DJB to Pottering. | |
DJB is a genius, responsible for all of the non-NSA asymmetric | |
cryptosystems, symmetric cryptosystems, and authenticated | |
encryption algorithms supported by TLS (curve25519, chacha20, | |
Poly1305). He's also the one who got us off of the | |
footgun-by-design, | |
broken-random-number-generator-will-spray-your-privatekey-every | |
where nondeterministic nonce signature schemes prior to Ed25519 | |
(the first standardized signature scheme which required | |
deterministic nonces). Oh yeah and the only post-quantum | |
cryptosystem that OpenSSH was comfortable shipping. | |
And pottering gave us pulseaudio. The gift that keeps on | |
giving. | |
cduzz wrote 1 hour 51 min ago: | |
What I said was that the first holy war of unix I remember is | |
the DJB vs everyone else. | |
As far as I can tell, as odd as DJB's designs may have | |
seemed, they were and are ... way better than what was and | |
still hold up today; most of the following "lets unix better" | |
designs seem to just adopt some of DJB's designs, typically | |
poorly. | |
Systemd certainly seems to have cribbed elements of | |
daemontools et al, but seemingly none of the notion of "least | |
privilege" ... | |
citizen_friend wrote 20 hours 8 min ago: | |
Did you expect more? | |
maxloh wrote 22 hours 12 min ago: | |
So many critical components in our system are maintained by just a | |
random good guy on the internet. | |
I can't help but think of another XZ crisis that is yet to come. | |
[1]: https://xkcd.com/2347/ | |
BLKNSLVR wrote 19 hours 11 min ago: | |
I think this may be the more accurate sentiment: | |
I can't help but think of all the other xz crises yet to be | |
discovered | |
rascul wrote 23 hours 58 min ago: | |
For three decades. I suspect he hasn't seen much money for the work, | |
but hopefully I'm wrong. | |
al_borland wrote 21 hours 28 min ago: | |
Seems like that might be an issue. | |
From his website⦠| |
>Iâm currently in search of a sponsor to fund continued sudo | |
maintenance and development. If you or your organization is | |
interested in sponsoring sudo, please let me know. | |
skywal_l wrote 21 hours 35 min ago: | |
From his personal page: | |
For the past 30+ years Iâve been the maintainer of sudo. Iâm | |
currently in search of a sponsor to fund continued sudo maintenance | |
and development. If you or your organization is interested in | |
sponsoring sudo, please let me know.[0] | |
[0]: | |
[1]: https://www.millert.dev/ | |
lenerdenator wrote 14 hours 50 min ago: | |
Sounds like a prime candidate for the Linux, Apache, Mozilla, | |
etc. foundations. | |
Y'know. Before some strangely-named benefactor from within the | |
UTC+03:00 time zone swoops in. | |
ece wrote 1 day ago: | |
Over the years I've switched from various cron daemons (anacron, | |
cronie), sysloggers (r-syslog, syslog-ng), network managers (netifrc, | |
NetworkManager) even ssh servers/clients (dropbear, openssh), and init | |
systems (sysvinit, openrc) and never have I felt the need to switch to | |
systemd despite reading some of Lennart's posts. I've used Gentoo over | |
the years, maybe that's why. | |
Doas is available on Linux as a sudo alternative, I think I'll be | |
trying that next, though I've only a limited amount of SUID binaries on | |
my system to being with, and don't need sudo's extra features. | |
korhojoa wrote 22 hours 57 min ago: | |
Now if then the commands run via some kind of privilege elevation | |
mechanism would require pledges to be used, that would be awesome: | |
[1] "This needs root", okay. But you only get exactly what you need. | |
[1]: https://news.ycombinator.com/item?id=38037075 | |
ece wrote 12 hours 7 min ago: | |
It's not pledge, but firejail and other SUID binaries like it | |
(bubblewrap, nsjail, etc..) are the only such ones on my system. | |
It's better than grsec/chroot sandbox I used back in the day on | |
Gentoo. I've also used shorewall, ufw, opensnitch for firewalls | |
over the years. I could go on. | |
kingspact wrote 1 day ago: | |
Linux is dead lol. | |
righthand wrote 1 day ago: | |
The big switch to systemd was always a mistake and this announcement | |
just proves it. | |
rstuart4133 wrote 1 day ago: | |
I'm not a fan of sudo. It's does so much it needs BNF to describe it's | |
configuration format. Who knows, maybe replacing the configuration | |
with polkit is a good idea. Still it's a stand alone binary with one | |
clear job to do, simple enough that one person has no trouble getting | |
their head around it so it's not surprising it hasn't had too many | |
problems over it's long life time. | |
This made me smile: | |
> sudo has serious problems though. It's a relatively large SUID | |
binary, i.e. privileged code that unprivileged users can invoke from | |
their own context. It has a complicating configuration language, | |
loadable plugins (ldap!), hostname matches and so on and so on. | |
That is a bit rich coming from the author of systemd, which must be in | |
the running for one of the largest bodies of code that must run as | |
root. It's also a very complex piece of code. That complexity is the | |
reason I was completely flummoxed by interactions between systemd and | |
dll's being exploited by the XZ utils hack to attack an unrelated and | |
uncompromised binary: openssh. Run0 is just an extension of that ball | |
of mud. It's a stretch to believe it will be more secure than sudo in | |
the long term, which is amusing because it appears Lennarts primary | |
argument is it will be more secure. | |
I'm not the only one who has noticed this: | |
[1]: https://lwn.net/Articles/971812/ | |
repiret wrote 22 hours 38 min ago: | |
I initially had the same reaction although having read the whole | |
thread, the author convinced me that SUID is in fact a fatally flawed | |
architecture and that run0's client-server architecture is correct. | |
Dudhbbh3343 wrote 1 day ago: | |
For anyone else unfamiliar with BNF: | |
[1]: https://en.m.wikipedia.org/wiki/Backus%E2%80%93Naur_form | |
klysm wrote 1 day ago: | |
> That is a bit rich coming from the author of systemd, which must be | |
in the running for one of the largest bodies of code that must run as | |
root. | |
Not really a far comparison given that itâs an init system | |
flaptrap wrote 1 day ago: | |
sudo: what, the problem is its attack surface is too big? Nothing | |
like systemd's. | |
Right now systemd, PID 1 won't finish on a Debian 12 (upgraded) which | |
I am slowly debugging. Neither journalctl nor syslog record messages | |
that flash on the screen. Systemd goes into a dark-flash-dark loop. | |
The developer should focus on getting systemd to work right before | |
pointing at others' supposed deficiencies. Software need to handle | |
error conditions and keep on plugging, especially if it replaces | |
init. | |
adw wrote 1 day ago: | |
Ian Jackson (former Debian project leader) has been on this train for | |
about 25 years now: | |
[1]: https://www.gnu.org/software/userv/ | |
georgyo wrote 1 day ago: | |
The article you linked seems to be in support that systemd is in fact | |
simpler than sudo. | |
Sudo, which only does privilege escalations, is only 1/3 the amount | |
of code of the entirety of systemd. | |
Systemd-run has been around for many years now, this is simply an | |
expansion of capabilities of features already exposed. | |
infotogivenm wrote 21 hours 44 min ago: | |
Em, that seems an extremely generous comparison, where did you come | |
up with that? Last I checked for example systemd relies on polkit | |
for policies, which drags in a javascript interpreter engine. If | |
the author thinks BNF is complex⦠| |
mzi wrote 1 day ago: | |
Isn't that link showing the opposite? That sudo is really large and | |
systemd isn't? They even compare systemd with wpa_supplicant and it | |
turns out they are the same size. | |
rstuart4133 wrote 1 day ago: | |
Not really. I'm not going the effort of breaking it down like he | |
did, so just looking at total lines in the source calculated with | |
"wc -l $(find . -type f)": | |
sudo: 284,103 | |
systemd: 1,981,535 | |
logicprog wrote 1 day ago: | |
I find your comment here sadly indicative of the level of | |
discussion around systemd from its haters. | |
Your metric is utterly misleading not only because you're almost | |
certainly counting non-code files, but more crucially, because | |
the systemd repository contains the code for *sixty-nine* | |
entirely separate binaries, separate tools under the overall | |
systemd project umbrella, so counting their collective code size | |
as if it is the code base of one single gigantic tool, a single | |
gigantic program that compiles into a single gigantic binary, | |
with all the interweaving that implies, is just disingenuous at | |
best. That number does not represent the size of a single attack | |
surface area, and pretending it does is nonsensical. It's like | |
pulling in the source of all of gnu and doing a line count. And | |
for the record, I've actually done this properly, cloning the | |
systemd repository and then reading the documentation to figure | |
out what directories and source files did what, and assembled a | |
list of the directories and source files that represented just | |
systemd-the-init-system, and got about 240,000 lines of code. | |
And remember, it won't actually be systemd the init system that | |
will be replacing sudo, it will be systemd-run, which is a | |
separate binary, with a separate memory space, and a separate | |
permissions model, that merely communicates with systemd the init | |
system to get certain things done. I guarantee you it's probably | |
smaller than the code base of sudo, and this architecture, as LP | |
points out if you actually read his thread on mastodon, far | |
better represents the methodology of running things with at least | |
privilege and privilege separation and so on, because instead of | |
having the binary that is called from unprivileged space managing | |
transitioning itself into privileged space and then doing things, | |
instead the binary always stays unprivileged and just | |
communicates via a strictly defined IPC protocol that gives it no | |
direct abikity to do anything with a process that was already | |
privileged instead, that can decide what to do on its own. | |
Let me leave you with this quote: | |
> If you build systemd with all configuration options enabled you | |
will build 69 individual binaries. These binaries all serve | |
different tasks, and are neatly separated for a number of | |
reasons. For example, we designed systemd with security in mind, | |
hence most daemons run at minimal privileges (using kernel | |
capabilities, for example) and are responsible for very specific | |
tasks only, to minimize their security surface and impact. Also, | |
systemd parallelizes the boot more than any prior solution. This | |
parallization happens by running more processes in parallel. Thus | |
it is essential that systemd is nicely split up into many | |
binaries and thus processes. In fact, many of these binaries[1] | |
are separated out so nicely, that they are very useful outside of | |
systemd, too. | |
> A package involving 69 individual binaries can hardly be called | |
monolithic. What is different from prior solutions however, is | |
that we ship more components in a single tarball, and maintain | |
them upstream in a single repository with a unified release | |
cycle. | |
[1]: https://0pointer.de/blog/projects/the-biggest-myths.html | |
diath wrote 1 day ago: | |
His methodology actually favors systemd, as sudo is for example | |
vendoring its dependencies in the repository. | |
diath@11km :: /tmp » git clone | |
https://github.com/systemd/systemd | |
diath@11km :: /tmp » cloc --match-f="(c|h)" systemd/src | |
C 1478 165173 | |
37638 584876 | |
C/C++ Header 1083 15580 | |
22432 59692 | |
diath@11km :: /tmp » git clone | |
https://github.com/sudo-project/sudo | |
diath@11km :: /tmp » cloc --match-f="(c|h)" | |
sudo/{src,include} | |
C 41 2104 | |
3359 16384 | |
C/C++ Header 36 797 | |
2159 5158 | |
rstuart4133 wrote 1 day ago: | |
Two things: | |
- Non code files were counted for both sudo and systemd. | |
That's because I'm lazy, not because I think it influences the | |
result one way or the other (I don't what effect it would | |
have). | |
- Separate binaries are not separate logical entities. | |
Pointing to separate binaries is a misdirection. systemd is a | |
set of binaries cooperating using RPC (dbus) to yield something | |
bigger than any single binary. The biggest hint they are | |
interconnected is they are in one source ball for a reason: so | |
these binaries can share a lot of code and interact in complex | |
ways. | |
As for systemd-run being "a separate binary, with a separate | |
memory space, and a separate permissions model", those things | |
didn't protect openssh being hit with the XZ Utils hack via | |
systemd. An unexpected interconnection is more than enough. | |
systemd abounds with interconnections. Being tightly | |
interconnected often gives you greater functionality, and in | |
the case of Run0 I suspect that is going to be a big win | |
because systemd has a lot of process isolation mechanisms built | |
in. But complex interconnected systems achilles heel is | |
security, and that's definitely true here. | |
rixed wrote 22 hours 1 min ago: | |
> But complex interconnected systems achilles heel is | |
security, and that's definitely true here. | |
And portability. | |
Sudo, being a truly independent binary, has been ported in | |
many OSes. Run0? | |
The issue with systemd ecosystem is not primarily technical, | |
it's the isolationism. | |
jchw wrote 1 day ago: | |
> Separate binaries are not separate logical entities. | |
They're separate programs, sometimes essentially completely | |
independent, sometimes sharing almost no code at all. For | |
example, systemd-init does not have dependencies on all of | |
the other programs, or vice versa. You can use the | |
systemd-boot bootloader without using systemd's init daemon. | |
You can use the systemd init daemon without using the | |
systemd-boot bootloader. | |
Having separate release tarballs isn't some special | |
distinction that makes things more "logically separate". | |
Besides, isn't this a goalpost shift of epic proportions? | |
> That is a bit rich coming from the author of systemd, which | |
must be in the running for one of the largest bodies of code | |
that must run as root | |
The point in indicting the size of systemd was the code that | |
runs as root, but the wc line count is counting tons of stuff | |
that not only doesn't all run as root, but some of it doesn't | |
even run under Linux. | |
> those things didn't protect openssh being hit with the XZ | |
Utils hack via systemd | |
A lot has already been said about this before, but the | |
systemd library that they included in the Debian and Fedora | |
patches to OpenSSH is by far one of the smallest surface | |
areas of any of the runtime dependencies. A bit ago, when I | |
ran libtree on sshd, I got this: | |
$ libtree `which sshd` | |
/run/current-system/sw/bin/sshd | |
âââ libgssapi_krb5.so.2 [runpath] | |
â âââ libkrb5.so.3 [runpath] | |
â â âââ libk5crypto.so.3 [runpath] | |
â â â âââ libkrb5support.so… | |
â â â â âââ libkeyut… | |
[runpath] | |
â â â â âââ libresol… | |
[runpath] | |
â â â âââ libkeyutils.so.1 … | |
â â â âââ libresolv.so.2 [r… | |
â â âââ libcom_err.so.3 [runpath] | |
â â â âââ libkrb5support.so… | |
â â â âââ libkeyutils.so.1 … | |
â â â âââ libresolv.so.2 [r… | |
â â âââ libkrb5support.so.0 [runpa… | |
â â âââ libkeyutils.so.1 [runpath] | |
â â âââ libresolv.so.2 [runpath] | |
â âââ libk5crypto.so.3 [runpath] | |
â âââ libcom_err.so.3 [runpath] | |
â âââ libkrb5support.so.0 [runpath] | |
â âââ libkeyutils.so.1 [runpath] | |
â âââ libresolv.so.2 [runpath] | |
âââ libkrb5.so.3 [runpath] | |
âââ libcom_err.so.3 [runpath] | |
âââ libk5crypto.so.3 [runpath] | |
âââ libz.so.1 [runpath] | |
âââ libcrypto.so.3 [runpath] | |
â âââ libpthread.so.0 [runpath] | |
âââ libldns.so.3 [runpath] | |
â âââ libssl.so.3 [runpath] | |
â â âââ libcrypto.so.3 [runpath] | |
â â âââ libpthread.so.0 [runpath] | |
â âââ libcrypto.so.3 [runpath] | |
âââ libpam.so.0 [runpath] | |
âââ libaudit.so.1 [runpath] | |
And that's just what you can see by looking at the shared | |
objects, there might be more at runtime. | |
You would have to ignore mountains of rationality in order to | |
come to the conclusion that systemd was remotely reasonably | |
"at fault" for what happened with the xz incident. Not only | |
that, even prior to the xz incident, systemd had already | |
fixed the problem that lead to the xz exploit, it just wasn't | |
shipping in Debian or Fedora yet; that's most likely why the | |
xz backdoor had to be rushed into the next releases in the | |
first place, because the window of opportunity was closing. | |
dijit wrote 1 day ago: | |
Regarding your first point: some people agree, most notably the | |
OpenBSD people who did something about it and wrote âdoasâ as a | |
replacement; which fits the most common use-cases of sudo without | |
fanfare. | |
logicprog wrote 1 day ago: | |
And, as LP points out, fails to solve the actual problem because | |
it's still locked into the exact same flawed Unix model, and | |
refuses to integrate with anything else in the system to get things | |
done in a better more systematic way. It's just a slightly refined | |
version of the same tired old Unix way | |
llm_trw wrote 22 hours 41 min ago: | |
If you don't like Unix maybe don't write software for a Unix | |
clone. | |
logicprog wrote 14 hours 18 min ago: | |
It's the best (or, least worst) OS we have right now, though, I | |
just want it to evolve on those Unix ideas. | |
dijit wrote 1 day ago: | |
Use something else then? | |
Linux won on Unix merits. | |
Feels a bit disingenuous to use that against it, especially when | |
including half the system libs has caused one major and highly | |
publicized security issue already | |
logicprog wrote 1 day ago: | |
> Use something else then? | |
What a tiresome response, but here, I'm feeling in a loquacious | |
mood, so I'll humor it. | |
First, what else would I use? I don't just want a "well | |
designed" operating system, I also NEED an open source, | |
customizable one that is compatible with the vast majority of | |
developer tools and build systems and toolchains â and that | |
is, without a doubt, Linux. I don't have a better option from a | |
practical standpoint. | |
And even from a design standpoint, there simply aren't any | |
better options, because Unix killed off all of the other good | |
alternatives, and now it's essentially the least worst option | |
we have right now. Basically the same situation we were in when | |
the Unix-Hater's Handbook was written. | |
I mean, what else have we got? | |
Windows? Windows NT, by way of OpenVMS so I've heard, had some | |
very interesting ideas that I think Linux would have done well | |
to imitate, like having a Common Language Runtime that lets you | |
directly interact with the objects and functions of every | |
application and code base on your system and communicate with | |
them in structured data (something Lisp Machines and Smalltalk | |
did first, better, but I digress), but we are beginning to get | |
that with DBUS and things like nushell, and Windows failed its | |
own promise there and has a vast panoply of its own flaws, not | |
least being Microsoft. So that's not really better at all. | |
MacOS? There are many ideas from MacOS I'm a huge advocate of | |
Linux stealing, but it is still fundamentally a UNIX, and in my | |
opinion has even more flaws than Linux has, especially since | |
Apple seems to have stopped caring about their software | |
quality. Not to mention, uh, >Apple<. | |
So you're basically just pulling the old "you think our social | |
system is deeply flawed in some ways and want to change it? | |
Just go live somewhere else then." | |
Furthermore, I was never intimating that everything Unix did | |
was completely irredeemable and the entire system we've spent | |
all this time and energy building should be thrown out | |
completely in favor of something entirely new. Instead I was | |
responding to the failure, the refusal even, to develop this | |
amazing testament to open source development and the operating | |
system design sensibilities ties that drive it forward or in | |
any new directions, among a certain crowd that determines the | |
worth of something new by how well it adheres to the philosophy | |
of the old. | |
I think we can build an excellent new system on the bones of | |
the Unix systems we have now, if nothing else because it's what | |
we've got to start with, and it did sort of have some | |
interesting ideas. I just think it requires actually thinking | |
outside of the box and reanalyzing our dogmatic adherence to | |
tired old traditions in light of everything we've learned and | |
everything that's changed in the interim, and the good ideas | |
from other operating systems that we can borrow, instead of | |
just repeating the same ideas over and over. | |
A flaw in our modern notion of operating system research and | |
development which has depressed even the creators of Unix | |
themselves: and while I don't think Plan 9 was the right move | |
exactly â I think it actually recapitulates many of the flaws | |
and fallacies of unix, such as the idea that everything being a | |
file is particularly useful, or that we should use plain text | |
designed first for people to read and only secondly for a | |
computer to process, in idiosyncratic formats, instead of | |
structured data â if even the original creators of Unix | |
believe that it should be transcended (Dennis Richie), and that | |
the original philosophy is dead (Rob Pike), maybe we should | |
learn something from that? | |
Maybe it's actually okay to look at what other good ideas there | |
may be in the problem space instead of being myopically, | |
slavishly devoted to a sad old religion. | |
> Linux won on Unix merits. | |
First of all, even if that was the case, that doesn't mean it | |
can't improve? | |
Just because, let's say, it's Unixy design was better than | |
anything else that was on the market at the time, and so it won | |
out against the other options that were available, doesn't mean | |
it is the best possible option â that it can't be improved or | |
developed, or even that the philosophy motivating it wasn't | |
fundamentally flawed and broken in some ways; all it means is | |
that whatever improvements could be made, or whatever was | |
broken in the philosophy to begin with, was less broken or less | |
bad than what happened to exist in competition with it. You're | |
making the exact same mistake that people with conservative | |
tendencies in life me and insisting that just because something | |
work in the past, for whatever reasons it did that, it can't | |
possibly be developed or improved upon. You aren't even saying | |
if it ain't broke don't fix it, you're saying if it wasn't | |
literally the worst, don't fix it. | |
In fact, I don't even think Unix won out in the server, | |
workstation, academic, scientific, and supercomputing Realms as | |
much as it did because of timeless technical merits and design | |
decisions based on eternal truths that mean we should continue | |
genuflecting to them forever (as much as the purveyors of the | |
Art of Unix would like us to think that) but instead because it | |
happened to have features that happened to be extremely | |
relevant merits in the particular time and place and context it | |
arose in, technologically and economically speaking. | |
Namely, that it combined extreme minimalism and portability | |
with a reasonable level of composability, even if the | |
composability it offered was awkward and half baked, and | |
because the other offerings had made their own more severe | |
tactical mistakes (Lisp Machines). | |
Thus it won out mostly almost by historical accident, as most | |
things do, because a proper level of composability and | |
integration, using defined IPC and structured data and well | |
integrated families of tools with non-Turing-complete | |
configuration languages was just too difficult for the hardware | |
of the time, and so the choices were either on operating system | |
with very little composability and flexibility and | |
programmability, or something like unix. | |
But that isn't the case anymore, yet because it did win, we've | |
retroactively deified it. | |
We can have our cake and eat it too if we choose to, if we | |
choose to not get sucked in to the North Korea like UNIX cult. | |
rixed wrote 21 hours 33 min ago: | |
Unix "way": | |
- what matters is composability (ie programs, possibly | |
running from different computers, being able to use each | |
other's output) | |
- simplicity is required for composability. Thus the | |
structure less file system and the "everything is a file" | |
design concepts. | |
The same merits as HTTP in the realm of protocols. | |
The appeal for a stricter and more principled approach are | |
understandable, and the road one end up favouring largely | |
depends on one's early experience I believe. | |
I, for one, grew up in a world where I could use either a | |
resilient Linux system that could run a treasure trove of | |
programs written long ago for different machines, or a more | |
modern and principled OS (windows) where a small glitch in | |
some non essential video driver would frequently bring down | |
the whole thing. I went for linux, it won maybe for its | |
merits, maybe by chance, and now I'm concerned that a whole | |
encompassing systemd will eventually bring us back where an | |
unrelated glitch, or backdoor, in an unrelated non essential | |
part will bring down the whole system. | |
skissane wrote 22 hours 1 min ago: | |
> Windows NT, by way of OpenVMS so I've heard, had some very | |
interesting ideas that I think Linux would have done well to | |
imitate, like having a Common Language Runtime that lets you | |
directly interact with the objects and functions of every | |
application and code base on your system and communicate with | |
them in structured data | |
The CLR is Microsoftâs answer to the JVM. It is not among | |
the ideas Windows NT inherited from OpenVMS. It is not part | |
of the core OS. Most apps donât use it. With the advent of | |
WinRT, there is arguably less of a push for its use than | |
there once was. | |
And when you talk about âcommunicating with structured | |
dataâ, I believe you are talking about PowerShell - which | |
apps donât participate in by default, you need to go to the | |
extra effort of writing PowerShell cmdlets for your app, and | |
many developers donât. You have to write them in PowerShell | |
itself, or else a CLI language such as C#, F#, C++/CLI, etc. | |
So if your app is written in C or (standard) C++ or Go or | |
Rust or Python or Java or JavaScript or Lisp or whatever, | |
integrating with PowerShell requires adding a new language to | |
your project - no wonder many donât bother | |
logicprog wrote 14 hours 20 min ago: | |
Makes sense. Like I said, there are a few vaguely | |
interesting ideas on Windows but it isn't good at all. | |
grosswait wrote 1 day ago: | |
Way too loquacious. Definitely not the Unix way. | |
gigatexal wrote 1 day ago: | |
Iâm here for it. I like systemd for the most part. I donât care for | |
this red window tinting tho. | |
ivanjermakov wrote 1 day ago: | |
Offtop: long mastodon/X threads are so inconvenient that I would not | |
even consider it a use case of such platforms. Write a blog post and | |
link it there, ffs | |
hoherd wrote 1 day ago: | |
I am continually baffled at people's use of X-Twitter/Mastodon for | |
this kind of writing. Thankfully I've found mastoreader, which is an | |
equivalent of threadreaderapp. | |
[1]: https://mastoreader.io/?url=https%3A%2F%2Fmastodon.social%2F... | |
kasabali wrote 1 day ago: | |
Sadly there's no "interaction" in blog posts | |
Xeamek wrote 1 day ago: | |
2 weeks ago I didn't understood the systemd hate. | |
But I tried to run udev-requiring program on non-systemd based distro. | |
And now I don't like systemd anymore. | |
deadbunny wrote 1 day ago: | |
I tried filling up a Tesla at a gas station. | |
And now I don't like electric cars anymore. | |
lupusreal wrote 1 day ago: | |
You joke but the inability of BEVs to make use of the gas station | |
infrastructure is probably their number one obstacle to mass | |
adoption. | |
shrimp_emoji wrote 1 day ago: | |
You just rent some parking space for the charge pylons. Probably | |
off to the side where the self-service wash hose/tire pump | |
usually is. | |
vdqtp3 wrote 1 day ago: | |
The energy bandwidth of a charger as opposed to a gas pump is a | |
huge issue right now. | |
Gas pumps can easily pump up to 10gpm [1], corresponding to 300 | |
miles of charge in 3-5 minutes as opposed to Superchargers, | |
which take 15 minutes to charge enough for 200 miles of | |
driving[2]. | |
When this is improved, it will make BEV's much more acceptable | |
to many people. [1] | |
[1]: https://en.wikipedia.org/wiki/Gasoline_pump#Design | |
[2]: https://www.energysage.com/ev-charging/tesla-superchar... | |
bhaney wrote 1 day ago: | |
You must absolutely despise libc | |
Xeamek wrote 1 day ago: | |
The difference is that I can solve libc dependency at comp time | |
(statically linked against it), while systemd dependencies require | |
runtime support. | |
lmm wrote 1 day ago: | |
libc has multiple independent implementations, if you don't like | |
one you can switch to another. Software that hard-depends on a | |
specific libc is indeed to be despised. | |
suprjami wrote 1 day ago: | |
So, you don't like a component because you ran software which | |
requires that component, and you intentionally ran it in an | |
environment without that component. | |
That does not make sense to me? | |
Xeamek wrote 1 day ago: | |
No. | |
I don't like a framework that promotes using components that are | |
arbitrary dependent on it. | |
To use udev, I need systemd-init, and to use systemd-init I need | |
systemd boot. | |
I really don't believe it MUST be this way, and those requirements | |
aren't at least partially arbitral. | |
Why systemd refuses to run in chroot? | |
BenjiWiebe wrote 21 hours 50 min ago: | |
You don't actually need to use systems-boot to use systemd-init. | |
They're two separate things. | |
vpzom wrote 1 day ago: | |
The popularity of systemd encourages people to require it, which is | |
the major problem | |
that said iirc udev was formerly separate and active forks still | |
exist | |
JoshTriplett wrote 1 day ago: | |
> The popularity of systemd encourages people to require it, | |
which is the major problem | |
The usefulness of systemd encourages people to require it. | |
Projects most often require it in cases where either there isn't | |
an alternative, the alternative isn't maintained, or the | |
alternative is missing functionality. | |
Xeamek wrote 1 day ago: | |
Self perpetuating growth. | |
Systemd integrates many functions so people default using it | |
and add even more functionality that bring even more people | |
into ecosystem. | |
Which is basically how every tech ecosystem works. | |
The problem is that linux is supposed to not be | |
just_another_centrally_controlled_ecosystem, so when systemd | |
abuses their popularity by enforcing whole ecosystem (rather | |
then cut itself into separate pieces), that is worrying | |
JoshTriplett wrote 9 hours 35 min ago: | |
It seems like you're attributing to perceived malice | |
("enforcing") what is better explained by a combination of | |
trying to get things done and not prioritizing replaceability | |
higher than the benefits of integration. In other words, a | |
project that simply has different priorities. | |
It turns out that many other people also like seeing stuff | |
get done more so than they care whether the project in | |
question is trivially replaceable. | |
rezonant wrote 1 day ago: | |
Well, I tried to run a Mac binary on Windows and it didn't work, so | |
now I don't like Mac. | |
broknbottle wrote 1 day ago: | |
sudo machinectl shell "${username}"@ | |
sudo /usr/bin/systemd-run --machine="${username}"@ --quiet --user | |
--collect --pipe --wait "${command}" | |
gnufx wrote 1 day ago: | |
In fact, if factotum were implemented on Unix along with an analogue to | |
the Plan 9 capability device, venerable programs like su and login | |
would no longer need to be installed ââsetuid root.ââ â… | |
[1]: https://plan9.io/sys/doc/auth.html | |
opless wrote 19 hours 58 min ago: | |
Plan9port has factotum. | |
Plan9 has a completely different security model. | |
The Hostowner (usually Glenda) is essentially "root" and you're at | |
the mercy of the filesystem regarding file privileges etc. | |
AFAIK there is no way to "become" glenda. | |
gnufx wrote 5 hours 17 min ago: | |
I haven't followed Plan 9 for ages, but I'm puzzled why Cox & co | |
wrote "Plan 9", then. However, the point was more about the | |
capability-oriented security in a Unix successor, and how you can | |
use file handles as a sort of cabability without the global | |
namespace. (They're often quoted as examples capabilities in | |
POSIX, but that's ignoring the global namespace.) | |
opless wrote 19 hours 52 min ago: | |
In fact, according to sys/src/cmd/auth/login.c it looks like once | |
you've logged it, you can shut the door using the capability device | |
so then it's game over, no more hostowner for you | |
airocker wrote 1 day ago: | |
I have seldom come across unix multiuser environments getting used | |
anymore for servers. Its generally just one user on one physical | |
machine now a days. I understand run0's promise is still useful but i | |
would really like to see the whole unix permission system simplified | |
for just one user who has sudo access. | |
hobobaggins wrote 9 hours 30 min ago: | |
We use Userify which manages multiple user logins (via SSH) and sudo | |
usage.. there are definitely many, many use cases for teams logging | |
into remote servers, and most security frameworks (PCI-DSS, HIPAA, | |
NIST, ISO 27000) require separate credentials for separate humans. | |
Sudo has some issues, but it works very well and is well understood | |
by many different tools. | |
airocker wrote 8 hours 57 min ago: | |
It could all be simplified and map one to one to your identity | |
provider credentials at a higher level. Having a complicated user | |
system on the servers makes it a problem. | |
superq wrote 8 hours 6 min ago: | |
Userify doesn't seem complicated.. it is just Linux users, | |
created with adduser just like you'd type in at the command line: | |
[1]: https://github.com/userify/shim/blob/master/shim.py#L227 | |
blablabla123 wrote 12 hours 30 min ago: | |
Yeah but elevated permissions may be needed from time to time anyway. | |
Either on the client, the baremetal server or the container. Running | |
everything as root is even for containers not recommended. | |
Considering how popular these have become, it's a bit of an irony | |
that systemd isn't available on the container without considerable | |
detours. | |
airocker wrote 9 hours 5 min ago: | |
One user with sudo for sysadmins on baremetal and a sudo access | |
without CAP_SYSADMIN on container should be good. | |
imtringued wrote 16 hours 43 min ago: | |
You run everything as root or how am I supposed to understand that? | |
Sudo exists to execute commands with a different user. It's an | |
abbreviation of "switch user (then) do" for a reason. | |
Most daemons run under a specific user. Things like docker that use a | |
root Daemon are a security nightmare. | |
airocker wrote 9 hours 9 min ago: | |
You dont need to use docker. Containerd or just just direct cgroup | |
manipulation: | |
[1]: https://access.redhat.com/documentation/en-us/red_hat_ente... | |
badgersnake wrote 19 hours 21 min ago: | |
I havenât seen it doesnât mean it doesnât exist. | |
airocker wrote 9 hours 7 min ago: | |
Exist does not mean it should keep existing if it is unnecessary | |
complexity from the past. | |
bayindirh wrote 20 hours 24 min ago: | |
Many, many daemons run under their own users. Just because a single | |
human is using the system, it doesnât mean the system has a single | |
user. | |
Also, people noted HPC, and other still very relevant scenarios. | |
unixhero wrote 21 hours 11 min ago: | |
The humans are now spawns of multithread shells and other things. | |
Linux land is still very multiuser oriented. But it is the rise of | |
the mschines instead. | |
jongjong wrote 1 day ago: | |
Technically not with virtual machines as the hardware is shared, | |
though I agree, nowadays accounts and access control of the system | |
belong to the virtualization layer below. The benefits of multiple | |
accounts per machine are tiny and not worth the complexity for server | |
setups. | |
We could significantly simplify things by getting rid of the account | |
system. The same could be said for a lot of systems like database | |
servers. Typically it's just one database, one user (your application | |
server) with full access. The account system is mostly an annoyance. | |
For big company use cases where you want to reduce attack surface, | |
why not spawn a second server with different credentials? Anyway big | |
companies typically have many database servers in a cluster and the | |
same credentials are shared by many server processes... The tendency | |
there is literally in the opposite direction. | |
zer00eyz wrote 22 hours 43 min ago: | |
>> Typically it's just one database, one user (your application | |
server) with full access | |
This is a terrifying way to access databases. | |
Super user, A Modify user (just below super but cant delegate | |
rights) for schema changes. A read/write app user... Probably a | |
pile of read only users who, have audit trails... You might want | |
some admins or analytics users (who have their own scheme | |
additions). | |
The words security and audit trails all spring to mind. | |
jongjong wrote 11 hours 27 min ago: | |
A simpler solution is to simply not give direct access to the | |
database to anyone who doesn't own a large stake in the project. | |
Expose it via a more restrictive CRUD interface with access | |
control in the application layer. | |
trueismywork wrote 1 day ago: | |
You'll just end up implementing multiuser support anyway due to | |
different permissions to different devices services | |
airocker wrote 1 day ago: | |
How about only in servers where you only have CPU/Memory/disk/GPU | |
with open source trusted drivers? | |
NewJazz wrote 1 day ago: | |
You only have one admin? How do you know who logged in, ssh | |
certificates? | |
medellin wrote 1 day ago: | |
Signed ssh certs make your life easy here | |
airocker wrote 1 day ago: | |
Only one human per machine. If you need to share the machine, make | |
multiple containers and give everyone a separate container. | |
NewJazz wrote 1 day ago: | |
You don't run any services where more than one person shares | |
responsibility for managing that service? E.g. kubernetes. That | |
is just one guy holding it up? | |
airocker wrote 1 day ago: | |
In an on-prem cluster, yes one guy or a few sysadmins who | |
either share passwords or can somehow put their keys in the | |
authorized keys file and ssh. | |
In the cloud, AWS/GCP let or not let an IAM user reach a | |
server. | |
mbreese wrote 1 day ago: | |
> across unix multiuser environments getting used anymore for servers | |
I guess it depends on the servers. I'm in academic/research computing | |
and single-user systems are the anomaly. Part of it is having access | |
to beefier systems for smaller slices of time, but most of it is | |
being able to share data and collaboration between users. | |
If you're only used to cloud VMs that are setup for a single user or | |
service, I guess your views would be different. | |
shrimp_emoji wrote 1 day ago: | |
> If you're only used to cloud VMs that are setup for a single user | |
or service, I guess your views would be different. | |
This is overwhelmingly the view for business and personal users. | |
Settings like what you described are very rare nowadays. | |
No corporate IT department is timesharing users on a mainframe. | |
It's just baremetal laptops or VMs on Windows with networked | |
mountpoints. | |
inopinatus wrote 19 hours 45 min ago: | |
> No corporate IT department is timesharing users on a mainframe | |
Not a mainframe perhaps, but this sentiment is flat wrong | |
otherwise, because that is how Citrix and RDS (fka Terminal | |
Server) do app virtualization. It's an approach in widespread use | |
both for enterprise mobile/remote access, and for thin clients in | |
point of sale or booth applications. What's more, a *nix as the | |
underlying infrastructure is far from unusual. | |
I have first-hand insider knowledge of two financial institutions | |
that prefer this delivery model to manage the attack surface in | |
retail settings, and a supermarket chain that prefers it because | |
employee theft is seen as a problem. Itâs also a model that is | |
easy to describe and pitch to corporate CIOs, which is | |
undoubtedly a merit in the eyes of many project managers. | |
One of the above financial institutions actually does still have | |
an entire department of users logged in to an S/390 rented from | |
IBM. Theyâve been trying to discontinue the mainframe for | |
years. Iâm told there are similar continuing circumstances in | |
airline reservations and credit card schemes; not just | |
transaction processing, but connected interactive user sessions. | |
This is what corporate IT actually looks like. It is super | |
different to the tech environments and white-collar head offices | |
many of us think are the universal exemplar. | |
twic wrote 1 day ago: | |
I wonder if they might be more common than you think. You will | |
never see someone standing up at a conference and describing this | |
setup, but there are millions of machines out there quietly doing | |
work which are run by people who do not speak at conferences. | |
Where i work, we have a lot of physical machines. The IT staff | |
own the root account, and development teams get some sort of | |
normal user accounts, with highly restricted sudo. | |
mbreese wrote 1 day ago: | |
Multi-user clusters are still quite common in HPC. And I think | |
you're not going to see a switch away from multi-user systems | |
anytime soon. Single user systems like laptops might be a good | |
use-case, but even the laptop I'm using now has different | |
accounts for me and my wife (and it's a Mac). | |
When you have one OS that is used on devices from phones, to | |
laptops, to servers, to HPC clusters, you're going to have this | |
friction. Could Linux operate in a single-user mode? Of course. | |
But does that really make sense for the other use-cases? | |
whimsicalism wrote 1 day ago: | |
is it? most HPC (if GPU clusters count) are probably in | |
industry and managed by containers | |
bayindirh wrote 20 hours 20 min ago: | |
HPC admin here. | |
Yes. First, we use user level container systems like | |
apptainer/singularity, and these containers run under the | |
user itself. | |
This is also same for non academic HPC systems. | |
From schedulers to accounting, everything is done at user | |
level, and we have many, many users. | |
It wonât change anytime soon. | |
whimsicalism wrote 7 hours 48 min ago: | |
I thought most containers shared the same user, ie. | |
`dockremap` in the case of docker. | |
I understand academia has lots of different accounts. | |
bayindirh wrote 7 hours 17 min ago: | |
Nope, full usermode containers (e.g.: apptainer) run | |
under the user's own context, and furthermore under a | |
cgroup (if we're talking HPC/SLURM at least) which | |
restricts the user's resources to what they requested in | |
their job file. | |
Hence all containers are isolated from each other, not | |
only at process level, but at user + cgroup level too. | |
Apptainer: | |
[1]: https://apptainer.org | |
pankajkumar229 wrote 17 hours 37 min ago: | |
there is no reason for users to be maintained in the | |
kernel. | |
bayindirh wrote 14 hours 43 min ago: | |
Can you elaborate on that? | |
birdiesanders wrote 23 hours 22 min ago: | |
Containers rely on many privilege separation systems to do | |
what they do, they are in fact a rather extreme case of | |
multi-user systems, but they tend to present as âsingleâ | |
user environs to the containerâs processes. | |
whimsicalism wrote 10 hours 13 min ago: | |
> they are in fact a rather extreme case of multi-user | |
systems | |
Are they? My understanding was that by default, the | |
`dockerd` (or whatever) is root and then all containers map | |
to the same non-privileged user. | |
airocker wrote 1 day ago: | |
you could potentially create multiple containers in that | |
machine which are single user and give to every user who needs | |
access. CPU/Memory/GPU can be assigned in any way you | |
want(shared/not shared). Now no user can mess up another user. | |
weebull wrote 18 hours 9 min ago: | |
Not containers, but cgroups, and that is how HPC clusters | |
work today. You still need multiple users though. | |
wongarsu wrote 18 hours 33 min ago: | |
Isn't that just reinventing multiuser operating systems? | |
Normal Linux already has the property that no user can mess | |
up any other user (unless they are root or have sudo rights) | |
SoftTalker wrote 23 hours 56 min ago: | |
It's not "that machine" it's a cluster of dozens or hundreds | |
of machines that is partitioned in various ways and runs | |
batch jobs submitted via a queuing system (probably slurm). | |
berkes wrote 1 day ago: | |
I always still split up "sysadmin" from "deploy". | |
Ephemeral setups (amongst which k8s) remove that need but introduce a | |
big load of other stuff. | |
Having a VPS that is managed by sysadmins (users with sudo rights, | |
authed with keys) and on which partly overlapping "deploy" users can | |
write to small parts and maybe do a passwordless "sudo sysctl restart | |
fooapp" but only that, is a nice and simple setup. | |
I manage at least seven of these. And nothing in me even considers | |
porting this to my k8s infra. | |
Edit: The reason for this setup is simple and twofold: deploy is safe | |
and clear: deployers can be confident that whatever crap they pull, | |
the server will churn on, data will be safe, recovery is possible. | |
And all devs/ops having their own keys and accts gives a trail, logs | |
and makes it very easy to remove that contractor after she did her | |
work. | |
eru wrote 20 hours 18 min ago: | |
Yes, we are moving more and more towards a system of immutable | |
deployments. | |
That's good! We don't patch executable binaries these days: we | |
just compile a new one from source, when we made a change. | |
Similarly, more and more we just build new systems (or their | |
images) from source, instead of mucking around with existing | |
systems. | |
theteapot wrote 1 day ago: | |
I think you mean systemctl. | |
8372049 wrote 1 day ago: | |
He probably meant sysadmin as in the account with sudo access. | |
BenjiWiebe wrote 22 hours 8 min ago: | |
s/sysctl/systemctl/ | |
berkes wrote 19 hours 14 min ago: | |
Correct. Typed it on mobile. | |
anonymous_union wrote 1 day ago: | |
in some other systems the concept has become overloaded. instead of | |
multiple real people as users, different software with different | |
permissions are different users. its not a bad abstraction. | |
airocker wrote 1 day ago: | |
Maybe containers are a better way of isolating processes as | |
mentioned in other comments. | |
mbivert wrote 1 day ago: | |
I've never understood the need for sudo(1) on single-user, physical | |
machines: I keep a root shell (su(1)) around for admin tasks, and | |
it's always been sufficient. | |
chgs wrote 1 day ago: | |
Everything I run with sudo is logged so I know how I messed up. | |
Nothing worse than ansible with its âsudo /tmp/whatever.shâ | |
which hides what itâs doing. | |
mbivert wrote 19 hours 16 min ago: | |
> Everything I run with sudo is logged so I know how I messed up. | |
FWIW, shells have a (configurable) history file. I'm not sure how | |
it compares to sudo's logging though. I also personally perform | |
little day to day admin tasks (I don't have as much time nor | |
interest to toy around as I used to, and my current setup has | |
been sufficient for about a decade). | |
> Nothing worse than ansible with its âsudo /tmp/whatever.shâ | |
which hides what itâs doing. | |
That's a nightmare indeed; for sensitive and complex-enough tasks | |
requiring a script, those scripts should at least be equipped | |
with something as crude as a ``log() { printf ... | tail | |
$logfile`` }. | |
lupusreal wrote 1 day ago: | |
One password is easier than two and it feels weird to use the same | |
password for both accounts. About half of my sudo invocations are | |
'sudo su' lmao. | |
mbivert wrote 19 hours 31 min ago: | |
> it feels weird to use the same password for both accounts | |
I'm not sure different passwords adds more protection for | |
single-user machines, especially when sudo(1) can spawn root | |
shells! | |
lanstin wrote 22 hours 10 min ago: | |
of mine are sudo bash. | |
MadnessASAP wrote 23 hours 51 min ago: | |
You're entering your own accounts password, not root, when you | |
use sudo. It's a security measure to prove our shell hasn't been | |
hijacked and to make you pause and acknowledge your running a | |
command that may affect the entire system. | |
You can also disable it in the sudoers file. | |
bmicraft wrote 1 day ago: | |
You could probably save a process with `sudo -i` | |
lupusreal wrote 12 hours 24 min ago: | |
Slightly less convienent to type. | |
airocker wrote 1 day ago: | |
Its just maybe easier way to not have to go to the root shell. | |
mbivert wrote 1 day ago: | |
Makes sense (I keep one warm in a tmux, two shortcuts away at | |
most, so it never occurred to me). | |
gnufx wrote 1 day ago: | |
Visit the research computing environment sometime, for instance. The | |
libzma SSH compromise was considered very worrying, after all. | |
richardwhiuk wrote 1 day ago: | |
That didn't need multi-users. | |
gnufx wrote 5 hours 25 min ago: | |
No, but that's the case I've overwhelmingly seen over the | |
decades. Anyway, are you going to redesign ssh not to require a | |
user, for instance? I assume you wouldn't want sshd running as | |
the putative single user. | |
[I'm all for replacing notions of privileges/permissions with | |
capabilities.] | |
TZubiri wrote 1 day ago: | |
access management is usually delegated to other systems that | |
supervise UNIX, like AWS | |
airocker wrote 1 day ago: | |
Or Kubernetes. Thats where a standard way of | |
authentication/authorization should be there. | |
rpgwaiter wrote 1 day ago: | |
NixOS may be helping multiuser make a comeback, at least it is for me | |
and my home servers. I no longer have to containerize my apps, i can | |
have one baremetal server with a dozen+ services, all with their own | |
users and permissions, and i don't have to actually think about any | |
of the separation. | |
Plus thereâs network shares. Multiple people in my home with linux | |
PCs, each with their own slice of the NFS pie based on user perms. | |
Sure, itâs not secure, but these are people I live with, not | |
state-sponsored hackers. | |
All that said, Iâd also love a simpler single-user perm setup. For | |
VMs, containers, etc it would be amazing | |
eru wrote 20 hours 17 min ago: | |
Containerisation (either with containers or via VMs) doesn't have | |
to be expensive. | |
In principle, you can have just exactly the binary (or binaries) | |
you need in the container or VM, without having a full Linux | |
install. | |
See eg Unikernels like Mirage. | |
inhumantsar wrote 1 day ago: | |
> i can have one baremetal server with a dozen+ services, all with | |
their own users and permissions | |
I've used nixos and I don't really see how nixos is special apart | |
from the declarative config. The same can/should be done with any | |
distro and any config manager. | |
And unless you were running Podman in rootless mode, the same setup | |
applies to containers too. | |
rpgwaiter wrote 20 hours 15 min ago: | |
Sure i could do this on debian, but like, i wont. Some software | |
comes packaged with nice scripts to provision new users for | |
running systemd services, but a lot do not. | |
For me and my home network, if the default security mode is | |
âmanage users yourselfâ, i chmod -R 777 on all applicable | |
files and call it a day. Nixos lets me be lazy, as all nixos | |
modules (that Iâve ever used) have their own user setups with | |
minimal permissions by default | |
tetris11 wrote 1 day ago: | |
DietPi does exactly the same using Debian | |
adastra22 wrote 1 day ago: | |
Iâm not sure how âI donât have to actually think about any … | |
the separationâ meshes with the fact that you explicitly setup | |
multiple users and configured file and group permissions | |
accordingly. You clearly put a lot of thought into it. | |
Alternatively, containers really are a no-thinking-required | |
solution. Everything maximally isolated by default. | |
matrss wrote 11 hours 31 min ago: | |
> Iâm not sure how âI donât have to actually think about | |
any of the separationâ meshes with the fact that you explicitly | |
setup multiple users and configured file and group permissions | |
accordingly. You clearly put a lot of thought into it. | |
That's the thing, with NixOS you usually don't have to explicitly | |
setup users and permissions. For most simple services, the entire | |
setup is a single line of code in your NixOS configuration. E.g. | |
services.uptime-kuma.enable = true; | |
will make sure that your system is running an uptime-kuma | |
instance, with its own user and all. | |
Some more complex software might require more configuration, but | |
most of the time user and group setup is not part of that. | |
airocker wrote 1 day ago: | |
There have been no big cves of container escapes for a while now. | |
I guess it can be considered secure enough. | |
lyu07282 wrote 17 hours 24 min ago: | |
A lot of Kernel privescs are also technically container | |
escapes, so 2 months ago was the last one actually: | |
[1]: https://www.cvedetails.com/cve/CVE-2024-1086/ | |
airocker wrote 9 hours 13 min ago: | |
but then even traditional multi-user would be compromised in | |
this case. | |
oceanplexian wrote 1 day ago: | |
Containers are isolated but a far, far cry from maximally | |
isolated. Theyâre still sharing a Linux Kernel with some hand | |
waving and cgroups. The network isolation and QoS side is | |
half-baked even in the most mature implementations. | |
HVM hypervisors were doing stronger, safer, better isolation than | |
Docker was 10 years ago. They are certainly no-thinking required | |
though which leads to the abysmal state of containerized security | |
and performance we have currently. | |
airocker wrote 1 day ago: | |
NixOS at it again :) | |
slackfan wrote 1 day ago: | |
Nope. I trust this about as far as I can throw it, and I will continue | |
editing my own files. | |
If I want NT, I'll just run an NT-based OS, thanks. | |
nan60 wrote 1 day ago: | |
Guess itâs time for me to switch to Void⦠| |
tommiegannert wrote 1 day ago: | |
This is playing on the difference between hoping that sudo does the | |
right thing juggling setuid and capabilities, and having a strict IPC | |
boundary between privilege levels. | |
It sounds like a great use of systemd, for those who want to use it. | |
AshamedCaptain wrote 13 hours 48 min ago: | |
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 gain any effective security | |
you need a 3 way IPC (1st level = the client, which is completely | |
untrusted; 2nd level = the request parser, which is trusted but runs | |
without elevated permissions; 3rd level = the actual elevator | |
process, which must run with elevated permissions). | |
EvanCarroll wrote 5 hours 58 min ago: | |
It's not clear why the request parser would have to be trusted. I | |
assume you're just speaking about the call to execve running in | |
context? That's not much of a request parser. At the point that you | |
tell `run0` to launch a shell, you're not calling the actual | |
commands to the shell the request parser, right? | |
I also think the notion of an untrusted client is kind of a hashed | |
out thing. As said in the post itself, `run0` is an interface to | |
`systemd-run`. `systemd-run` as a client may be more _involved_ but | |
it doesn't seem like that has any relevance to whether or not it's | |
more secure. It's a separate layer for the insecurity. While sudo | |
is a single process, if it was two processes it wouldn't all have | |
to run as root. That by necessity means something that was | |
previously running as root isn't, which makes it more secure -- not | |
less, right? | |
The actual elevator process is systemd itself which already runs as | |
init on every machine you'll have `run0`. But by nature it's always | |
the top of the process tree, it seems like it's _less_ complex to | |
have systemd-init the immediate parent process. There are fewer | |
thing that can leak into or be inherited by the spawned process. | |
AshamedCaptain wrote 4 hours 50 min ago: | |
> It's not clear why the request parser would have to be trusted | |
[...] I assume you're just speaking about the call to execve | |
running in context | |
No, I'm talking about the part which is going to parse the | |
command line, arguments, environment, decide whether the user is | |
allowed the elevation or not, decide which environment, file | |
descriptors, etc. are to be passed through, etc. All of this | |
must NOT be in the same context as the caller, as it can simply | |
fake all these decisions. You need to handle this from a process | |
running in another context (suid or not). | |
> While sudo is a single process, if it was two processes it | |
wouldn't all have to run as root | |
Yes it would ? At least one of them would need to be suid for the | |
actual execution. But the problem is that the process which was | |
NOT suid would be running as the same user as the caller, so by | |
the same reason as above -- you cannot trust what it does. The | |
only thing the non-root process would be able to do is to massage | |
the request a bit, then forward it (IPC!) to the root/suid | |
process which you CAN trust. We are just moving the security | |
border, and it is not clear what would be gained by it. | |
In this proposal, instead of a suid binary, you have a constantly | |
running "sudod" process (or worse, pid 1), but otherwise is the | |
same. Everything must be IPC'd to it. | |
> There are fewer thing that can leak into or be inherited by the | |
spawned process. | |
To have this IPC complexity just because apparently we can't | |
figure out how to do suid without inheriting anything is bonkers. | |
As a trade-off you now have a user-accessible IPC system with the | |
_gazillion_ possible vulnerabilities it entails. At least before | |
you needed root to talk to pid1.. | |
anonymous_union wrote 1 day ago: | |
holy shit this guy knows no shame | |
cesaref wrote 1 day ago: | |
Let's assume for a moment that it is lower risk than sudo (which is the | |
problem is it addressing), why isn't it also called 'sudo', designed to | |
behave the same as the thing it is replacing, so that anyone (and any | |
scripts) that currently use sudo can carry on and be oblivious to the | |
security benefits this new implementation offers? | |
I'd instead like to see a post saying something like 'on systemd based | |
systems, a more secure implementation of sudo is provided', and all the | |
clever whatever it is happens behind the scenes, and frankly i'll never | |
need to know about it. | |
SkyMarshal wrote 1 day ago: | |
alias sudo="run0" | |
If run0 supports the same flags and parameters they'll be | |
interchangeable with just an alias. | |
cesaref wrote 17 hours 45 min ago: | |
I thought this was a security fix? Let's say I find a problem in | |
ssh, I don't update it, call it 'newssh' and tell people to use an | |
alias to point ssh to newssh do i? I just fix the app. | |
zzo38computer wrote 1 day ago: | |
Presumably because it uses different options and other different | |
stuff, it has a different name. However, it might be useful to have a | |
command "sudo" which emulates the options of sudo so that you can | |
still use the same "sudo" command on systemd-based systems as well as | |
on non-systemd-based systems. I don't really know how well that would | |
work, though. | |
cesaref wrote 17 hours 50 min ago: | |
Maybe you've not understood. I'm asking, why does it have different | |
options? Is there a reason for that? If not, make it compatible, so | |
a drop in replacement. Otherwise we're just spamming new commands | |
at people, and the old sudo will probably end up living on | |
alongside the new on systemd based systems just to keep scripts and | |
the like working. | |
voiper1 wrote 1 day ago: | |
calling it sudo would create the expectations that all the options, | |
config, and usage is exactly the same. | |
It would appear that it's _functionally_ the same, but using a | |
different mechanism and with a new name so they don't want to be | |
locked down to all the other stuff. | |
agilob wrote 1 day ago: | |
Because there already is jq-go and jq-python. One of them is called | |
jq in linux the other is called jq in MacOS. They are not compatible | |
and you find out you're using the other one after 6 hours of | |
screaming at the computer. | |
bhaney wrote 1 day ago: | |
Is it "run-zero" or "run-oh"? | |
mise_en_place wrote 1 day ago: | |
This is just a complete disaster. Ever since libxz has shown how | |
bloated and spaghetti code systemd is, now they want to make it seem | |
like they're going to have "security" in mind. What a joke. | |
mzs wrote 1 day ago: | |
[1]: https://github.com/secnigma/CVE-2021-3560-Polkit-Privilege-E... | |
jmclnx wrote 1 day ago: | |
Why ? I guess you do not get this unless you have systemd, that is | |
fine by me. If I would use anything outside of sudo I would go to | |
doas. | |
My home distro does not have systemd, so I guess I may never see run0. | |
I have been evaluating the various BSDs for a few years in case my | |
distro is forced to use systemd and friends. The distro I use is | |
fighting the good fight against large monolithic tools, but it is | |
having a hard time trying to avoid these monolithic tools. | |
With Linux slowly forcing systemd, Wayland, various Desktop | |
Environments and now this, my move to a BSD may happen sooner that | |
later. | |
Curious, I wonder how close run0 is to how Windows raise auths ? With | |
LP now working for Microsoft, is he cloning tools from Windows for use | |
in Linux ? | |
dang wrote 1 day ago: | |
Url changed from [1] , which points to this. | |
[1]: https://www.osnews.com/story/139490/run0-a-systemd-based-more-... | |
throw0101b wrote 1 day ago: | |
First comment at the LWN: | |
> [â¦] I think calling the flags "setuid" (as lwn appears to prefer?) | |
just blurs things, since that's the name of a syscall (setuid()), which | |
does something related, but is not actually involved in the concept | |
that the inode SUID flag is about. | |
> Hence, I am a bit confused what that comment here is supposed to | |
achieve? It just creates confusion? | |
> Lennart | |
* [1] Reply by corbet: | |
> Lennart, the purpose was to be sure that readers knew what the term | |
meant in the quote, nothing more. | |
Never change, Lennart, never change⦠| |
[1]: https://lwn.net/Articles/971747/ | |
mzs wrote 1 day ago: | |
the right person to replace sudo, not: [1] PS: [2] edit, this one | |
went on for more than a year: | |
[1]: https://github.com/systemd/systemd/issues/6237 | |
[2]: https://pwnies.com/systemd-bugs/ | |
[3]: https://github.com/systemd/systemd/issues/6632 | |
withinboredom wrote 1 day ago: | |
I don't understand the point of creating an entirely new shell | |
inheriting almost nothing. Seems like that would cause a lot of issues | |
(i.e., sudo make install) | |
Arnavion wrote 1 day ago: | |
That's how sudo already works on most (all?) distros. Eg Debian 12 | |
has: | |
Defaults env_reset | |
... which will clear almost everything that `make install` would've | |
used. OpenSUSE TW has: | |
Defaults always_set_home | |
Defaults env_reset | |
Defaults env_keep = "LANG LC_ADDRESS LC_CTYPE LC_COLLATE | |
LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES LC_MONETARY LC_NAME | |
LC_NUMERIC LC_PAPER LC_TELEPHONE LC_TIME LC_ALL LANGUAGE LINGUAS | |
XDG_SESSION_COOKIE" | |
... which is a lot more, but will still clear whatever `make install` | |
would've used. | |
Anything you need to give to `make install` should be given | |
explicitly, like `sudo make INSTALL_ROOT=$INSTALL_ROOT install` or | |
whatever. | |
gcbirzan wrote 1 day ago: | |
If you're using autoconf/automake, you don't need to do that. | |
westmeal wrote 1 day ago: | |
what else is systemd going to eat :/ | |
atoav wrote 1 day ago: | |
It would be really funny if systemd tried to replace pulseaudio. | |
figomore wrote 1 day ago: | |
Pulseaudio was created by Lennart Poettering. | |
atoav wrote 20 hours 5 min ago: | |
Hence why it would be funny. | |
Narishma wrote 1 day ago: | |
pulseaudio is already in the process of being replaced by pipewire. | |
atoav wrote 20 hours 4 min ago: | |
Jup and that is good. Finally sending audio to multiple devices | |
isn't a pain anymore. | |
abridgett wrote 1 day ago: | |
I'm not sure it can replace non-trivial setups - sudo/doas looks set to | |
stay. | |
e.g when you need to restrict a set of users to run only certain | |
applications with certain other users. sudo can do this (even if the | |
config format can be painful). | |
agwa wrote 1 day ago: | |
Good news! run0 will use polkit[1], which uses JavaScript for its | |
rules[2], so there's no limit to how complex your rules can get! | |
On the other hand, maybe adding a JavaScript interpreter to Linux's | |
trusted computing base isn't good news... [1] | |
[1]: https://mastodon.social/@pid_eins/112353420303876549 | |
[2]: https://www.freedesktop.org/software/polkit/docs/latest/polk... | |
rcxdude wrote 1 day ago: | |
It's a heck if a lot better than a random smattering of shared | |
libraries getting pulled into a random high-priviledge context | |
which also inherits some other context from whoever is asking for | |
authentication. Polkit gets a lot of flack but PAM is absolutely | |
mad. | |
akira2501 wrote 1 day ago: | |
If the lesson of xz was "reduce supply chain attack surface" then | |
the freedesktop people clearly haven't received it yet. | |
bmicraft wrote 1 day ago: | |
Fedora has used PolKit for 12 years now, and the javascript rules | |
have probably been a thing for about as long. | |
akira2501 wrote 15 hours 57 min ago: | |
Doctors recommended cigarettes for decades. What should give | |
everyone similar pause is xz was found unintentionally. | |
stop50 wrote 1 day ago: | |
Thats why i moved every sudoers rule to ldap. Much nicer to configure | |
and no need for files with the same content on multiple servers. New | |
users are added and removed fast and i can check the rule on any | |
server. | |
lupire wrote 1 day ago: | |
What's the goal? | |
If the host is to get most scenarios off sudo, exceptions aren't a | |
problem. | |
If the goal is to delete sudo, exceptions matter, and migrating what | |
is migratable will clarify what the remaining requirements are. | |
cozzyd wrote 1 day ago: | |
sure but very few people (relatively) are doing stuff like that? | |
StayTrue wrote 1 day ago: | |
Perhaps the nomenclature should be updated from GNU/Linux to | |
GNU/systemd/Linux. | |
phone8675309 wrote 1 day ago: | |
Until systemd consumes the kernel and then it will be GNU/systemd | |
bitwize wrote 1 day ago: | |
[1] Waiting for this to no longer be fake. | |
[1]: https://www.tumblr.com/wizardofbits/96856361060/rethinking... | |
CamouflagedKiwi wrote 1 day ago: | |
Or it consumes every other part of the GNU runtime and it becomes | |
systemd/linux | |
Zuiii wrote 22 hours 57 min ago: | |
At it's growth rate, it'll be just systemd. I'm only half joking | |
unfortunately. | |
segasaturn wrote 1 day ago: | |
I asked this in a thread about this from last night and didn't get a | |
reply. For context, the way "run0" works is to apparently send a signal | |
to polkit that requests a command under the root user's ID and | |
permissions, thereby getting a privileged shell without SUID: | |
> How hard would it be to create a program to send a signal to polkit | |
"impersonating" run0 and obtain a root shell without entering a | |
password? | |
Anybody know how this is being authenticated? | |
thayne wrote 1 day ago: | |
I would assume the authentication happens in polkit, so a fake client | |
would only be able to run a command if it had the necessary | |
credentials. | |
ongy wrote 1 day ago: | |
Without looking at the he specific implementation | |
There should be a service running as uid=0 that exposes an | |
unprivileged API. | |
This service then takes the RPC and does authorization with polkit. | |
I.e. the unprivileged part doesn't talk to polkit directly. But a | |
privileged part uses polkit instead of a custom sudoers style config. | |
akagusu wrote 1 day ago: | |
Piece by piece, Red Hat is taking over the Linux ecosystem. | |
immibis wrote 1 day ago: | |
We don't have to use their stuff. systemd actually does a good job of | |
managing services' up and down state - it's the rest of the bundled | |
functionality that people take issue with - and if service up and | |
down is all you want, there's runit. | |
Wayland seems to be a solution without a problem, and it's only | |
winning by default. I've toyed with the idea of forking Xorg - the | |
code is a bit odd by today's standards, but I didn't find any direct | |
problem with it, and it works fine - the biggest problem I discovered | |
in Xorg is a lack of project management as nobody knows what it | |
should and shouldn't do | |
My gentoo system has some gentoo-specific fork of udev without | |
systemd in it. | |
We don't have to use run0 and can just use sudo. | |
Spivak wrote 1 day ago: | |
I guess but in this case it's doing something that sudo doesn't do | |
â get privs from a daemon instead of setuid, and using something | |
that systemd already did (systemd-run). | |
Is it that weird that they would make a runas frontend when all the | |
pieces of it were lying around? | |
izacus wrote 1 day ago: | |
Well, they're the only ones actually funding development of the | |
ecosystem, aren't they? | |
The rest just do a lot of opinoning and complaining and not that much | |
of developing. | |
superkuh wrote 1 day ago: | |
The implicit premise of this comment is that linux is broken and | |
needs to be changed. It isn't. The changes are not inherently good. | |
Development is not inherently good. Just look at Gtk3 from 2014 to | |
2024. It was far more functional in 2014 (re: keyboard input) and | |
now that has been removed because "progress". | |
sophacles wrote 1 day ago: | |
No one is stopping you from running a 2014 version of your | |
favorite distro. Seems like a good way to address your concerns. | |
superkuh wrote 1 day ago: | |
Indeed. I have been using Ubuntu 14.04 under ESM for the last | |
10 years. But that ESM support is ending in 2024. I've tried | |
modern distros using modern Gtk3 and they're lousy with file | |
chooser bugs. I've tried patching Gtk3 gtkfilechooserwidget.c | |
myself but I can only fix it for the first file->open dialog, | |
not subsequent ones. Attempts to get help in #Gtk over the last | |
5 years have been rebuffed in IRC and ignored/closed repeatedly | |
on the issue trackers: | |
[1]: https://gitlab.gnome.org/GNOME/gtk/-/issues/5872 | |
throwaway11460 wrote 1 day ago: | |
Nobody needs to adopt the changes. Everybody did because it's | |
better than the alternatives. There are still systemd-less | |
distros if you like it. | |
thecrash wrote 1 day ago: | |
Yes, theoretically we could just stick with old software that | |
was perfectly good at the time. The problem is that the | |
ecosystem moves together - there's an emergent consensus about | |
what is "current" (i.e. what's obligatory to support) across | |
many different projects. | |
So each component is interrelated, and holding one back means | |
sacrificing compatibility with the new features (and security | |
fixes!) of many other components. | |
In this way we can find ourselves dragged into using software | |
that is actually worse than it used to be. This is important to | |
note because it means our use of a component is not proof that | |
it's good. It just means that the ecosystem is good enough | |
overall that it can force us to accept devolved versions of | |
certain components. | |
It makes sense to argue about what the consensus of the | |
ecosystem should be even while recognizing that we will | |
probably accept it regardless. | |
superkuh wrote 1 day ago: | |
My issue is not with systemd. My issue is with the argument | |
that all development is good. In this example I am pointing out | |
how Gtk3 has suffered from development attention from GNOME | |
over the last decade and became worse. | |
Maybe run0 is worse than sudo. Maybe not. I have no personal | |
experience on that topic and I doubt anyone here does. | |
throwaway11460 wrote 1 day ago: | |
It's the same thing though - nobody is forced to accept their | |
changes, you can fork at any time. Or stop using it, keep | |
using gtk2, etc. | |
immibis wrote 1 day ago: | |
Reality is more nuanced than that, because even if the | |
newer software is worse, if it markets itself better it can | |
persuade other projects to drop support for the old | |
software. | |
cozzyd wrote 1 day ago: | |
Ironically enough, Lennart now apparently works for Microsoft. | |
(though to be clear, I like systemd and I think Lennart is a very | |
good engineer). | |
oceanplexian wrote 1 day ago: | |
Thatâs a great fit for him since systemd appears to lift their | |
monolithic design practices and force them on the Linux community. | |
fn-mote wrote 1 day ago: | |
Overall, this seems great. | |
However... | |
> [...] by default it will tint your terminal background in a reddish | |
tone while you are operating with elevated privileges | |
?!! ouch ... seems orthogonal to the actual important parts. | |
Disclaimer: I didn't try it. | |
sfink wrote 9 hours 31 min ago: | |
Yeah, that's the part that stuck out for me. "sudo is bad because it | |
does all these things it shouldn't do instead of just the one thing | |
it's for and nothing else. My tool is good because it does just the | |
one thing it's for â plus this other random thing because I think | |
it's cool." | |
whalesalad wrote 23 hours 9 min ago: | |
This is a thing in certain environments. I donât mind it. | |
bityard wrote 1 day ago: | |
This is a perfect example of a choice that a developer makes to suit | |
his/her personal preference and environment, believing that everyone | |
does (or should) use their computer the same way. Which is sadly | |
becoming a more common trend. | |
I like the idea, but I don't think it should be on by default. The | |
rest of us have just used root-specific shell prompts for the last | |
few decades or so. | |
TZubiri wrote 1 day ago: | |
It's fine. | |
Not every software needs to be infinitely configurable and open | |
source just in case the configurations don't cover the needs of | |
all. | |
We need opinionated software, if you don't want to make any choice | |
for me, you can't even give me an assembly editor for fear of | |
forcing your CPU arch of choice. | |
bityard wrote 8 hours 3 min ago: | |
I don't understand the part about the assembly editor, but I'm | |
not sure I agree with the rest. | |
Whenever I hear someone describe their software as "opinionated," | |
I have found what that usually means is that the developer thinks | |
they are smarter than everyone else and all of the unfriendly | |
attitude that usually comes along with that. | |
Whoever made the decision that run0 should turn your terminal red | |
by default doesn't understand that there are practically infinite | |
terminal configurations out there that this will interfere with | |
or be outright incompatible with. My argument is that the | |
decision comes from a place of ignorance of the sheer diversity | |
of the users of the software, not from a place of, "we are so | |
smart, and are the first ones to think of this feature." | |
aragilar wrote 18 hours 9 min ago: | |
You can't think of ways this could break things? I would find | |
this a useful feature, but I'm also aware of how this works, and | |
the issues it could cause. | |
acdha wrote 9 hours 22 min ago: | |
It could, but this is a non-default tool focused on new use so | |
the first question Iâd ask is how many of the people using it | |
are running the weird edge-case terminals where thatâd break | |
something. I wouldnât want to end up in a Microsoft-style | |
trap where nothing can improve because someone somewhere | |
depends on strict fidelity with 1993. | |
Spivak wrote 13 hours 29 min ago: | |
No? Of all the esoteric escape sequences that terminals handle | |
the ones that change colors are well trodden. | |
aragilar wrote 12 hours 28 min ago: | |
There are at least 3 different ways of expressing colour as | |
covered by [1] , and given the wide propensity of newer | |
terminals to misidentify what they are (I know I have some | |
additional checking in my shell startup to unbreak things if | |
needed), and/or bad termcap/terminfo settings on older | |
systems, sending terminal sequences that are apparently | |
supported but are not happens surprisingly often (enough such | |
that I've made sure to always install two different terminals | |
which use different rendering backends, e.g. xterm and VTE). | |
[1]: https://en.wikipedia.org/wiki/ANSI_escape_code#Color... | |
shrimp_emoji wrote 1 day ago: | |
Counterpoint: GNOME and the modern GTK framework | |
(I needn't say more.) | |
metalspoon wrote 1 day ago: | |
Yes. I prefer having tools that do one thing well. That's the | |
point of unix. How the user uses them should be up to her. | |
GNOME offering a monolithic environment with heavy opinionation | |
is the opposite. | |
flexagoon wrote 11 hours 38 min ago: | |
How is GNOME a "monolithic environment"? The entire GNOME | |
ecosystem is basically small apps that do a single thing | |
well: | |
[1]: https://apps.gnome.org/ | |
johnny22 wrote 1 day ago: | |
actually you do, because gnome is great | |
yoyohello13 wrote 1 day ago: | |
Gnome is great if you're willing to do things their way. I Like | |
Gnome a lot actually. | |
flaptrap wrote 1 day ago: | |
Gnome's UI peaked at 2.32. Find out how the users operate and | |
implement so users can work efficiently. Don't make changes | |
just to make your mark or to make users work on the desktop | |
like they see on a cell phone. That is so basic. | |
abenga wrote 21 hours 39 min ago: | |
Gnome is always getting better (if you want to do things | |
the Gnome way). Why should a DE show any elements begging | |
to be clicked on my desktop while I am working (window | |
list, etc)? I am only interested in what's in my IDE, | |
terminal, and browser. Present Gnome comes closest to my | |
ideal of fading into the background and letting me focus on | |
my tasks. | |
loeg wrote 22 hours 57 min ago: | |
These days KDE gets a lot of the same things right that | |
GNOME 2 did. | |
jimbosis wrote 23 hours 35 min ago: | |
I don't know if you are DE shopping, but I've been very | |
happy for the past few years with the MATE Desktop | |
Environment, which "...is the continuation of GNOME 2. It | |
provides an intuitive and attractive desktop environment | |
using traditional metaphors for Linux and other Unix-like | |
operating systems." [1] Among a great number of things I | |
really like, I will mention that Caja, the MATE version of | |
GNOME 2's Nautilus file manager, can still be switched to | |
spatial mode. [2] Generally speaking, I too really liked | |
GNOME 2.32 and its predecessors, and, as far as I'm | |
concerned, MATE is as it describes itself. | |
EDIT: Wording mistake. | |
[1]: https://mate-desktop.org/ | |
[2]: https://en.wikipedia.org/wiki/Spatial_file_manager | |
MadnessASAP wrote 23 hours 47 min ago: | |
I have no idea why Gnome keeps on insisting on breaking | |
expectations. From the shell as a whole to the widgets and | |
even the window titlebars they seem to insist on being | |
different for the sake of being different. | |
abenga wrote 21 hours 36 min ago: | |
Because their choices are better, at least for some of | |
us. Users who prefer the traditional desktop paradigm | |
have a wealth of alternative DEs to choose from. | |
MadnessASAP wrote 21 hours 26 min ago: | |
I suppose my brutally minimalist Sway config with | |
barely there titlebars and a skinny little status bar | |
and not an icon, button, or widget in sight doesn't | |
give me great standing to call for a respect of | |
conventions. | |
I suppose I should say I found Gnomes luridly chunky | |
decorations and widgets to be personally offensive. | |
abenga wrote 20 hours 7 min ago: | |
What widgets? Gnome has just the one black bar at the | |
top. | |
MadnessASAP wrote 19 hours 37 min ago: | |
And it's a thick monster with all kinds of extra | |
crap (I'm my not so humble opinion) shoved in it. | |
abenga wrote 17 hours 33 min ago: | |
It literally has an activities button, the time | |
and date, and a tiny button for interacting with | |
settings on the right. | |
NekkoDroid wrote 1 day ago: | |
I tried it a bit ago (when it was still called uid0, pre-release), I | |
also wasn't a fan of the tinting. | |
I like the intent behind it, but some terminals already tint the | |
header color when running sudo, I haven't tested if its done | |
specifically for sudo or if its in a more generic way that could | |
handle this as well. | |
withinboredom wrote 1 day ago: | |
I can think of a number of things this tinting would break. | |
seanc wrote 1 day ago: | |
It violates the principle of Least Surprise; if I'm invoking run0 | |
I'm expecting it to run my program with a different UID and | |
return the same stdout I'd have gotten if I had just run the | |
program in my shell. Not inject a whole bunch of color control | |
bytes in there. Which hopefully my terminal will handle. Unless | |
it doesn't. | |
I'll give them the benefit of the doubt and assume they only do | |
this if $TERM supports color. But still. That $TERM variable | |
can surprise a poor programmer in all sorts of ways. | |
zeroimpl wrote 1 day ago: | |
But sudo already doesnât do that either. Eg sudo may ask for | |
a password, and output some control sequences which hide the | |
text so your password is not visible. | |
This feels like much ado about nothing. | |
Edit: Also donât forget the âwith great power comes great | |
responsibilityâ blurb that sudo likes to output. I know that | |
doesnât happen in scripts when output is redirected, but | |
Iâm sure run0 will figure that out too. | |
withinboredom wrote 19 hours 43 min ago: | |
> sudo may ask for a password, and output some control | |
sequences which hide the text so your password is not | |
visible. | |
You can turn this off for certain users and/or programs. | |
dijit wrote 1 day ago: | |
asking for a password to do an authenticated action is about | |
as far away from surprising as I can legitimately reason | |
about. | |
The contextual blurb does have a way of disabling it in a | |
persistent config, which is easy enough to set. It also goes | |
to stderr and not stdout and does nothing to alter the output | |
of the command itself. | |
It also does not show if you have NOPASSWD: set in your | |
sudoers. So even less surprising. | |
10000truths wrote 1 day ago: | |
Any sane command line program will only output color codes if | |
isatty(STDOUT_FILENO) succeeds. | |
withinboredom wrote 1 day ago: | |
That can succeed in a number of cases, where it actually | |
isn't a tty with a user on the other end of it. There are a | |
number of internal tools at work that only output logging if | |
there is a tty and thus are run in their cronjobs with a tty. | |
If there were unexpected color outputs in the logs, that | |
would suck since the log aggregators probably wouldn't know | |
what to do with it. | |
lupire wrote 1 day ago: | |
Can you name any? | |
snvzz wrote 14 hours 22 min ago: | |
XMODEM and the like expect the terminal stream to not have | |
garbage added by e.g. run0. | |
The terminal line should be clean between XMODEM at the | |
terminal emulator and at the client end. | |
withinboredom wrote 1 day ago: | |
Containers run with a tty attached but no console on the other | |
end and then trying to read the logs, for starters. | |
Additionally, as mentioned, conflicts with the user's color | |
scheme or even the program's. Further, it's possible to do this | |
without the help of run0, so I suspect users already doing that | |
are going to get their colors messed up and be annoyed. For | |
example, prod machines are usually red, and running as root on | |
a prod machine is royal purple. If this is used, seeing a red | |
background instead of a purple one is likely non-desirable. | |
shiomiru wrote 1 day ago: | |
If the program you're running prints red text, then you get red | |
bgcolor with red fgcolor. Good luck reading that. | |
(Also, users with the wrong color scheme get that experience by | |
default. Though that is a niche use case enough that I'd be | |
surprised if systemd devs cared about it.) | |
dsr_ wrote 1 day ago: | |
The user's choice of color schemes. | |
Karellen wrote 1 day ago: | |
> I also wasn't a fan of the tinting. | |
From the linked mastodon thread: | |
> For example, by default it will tint your terminal background in | |
a reddish tone while you are operating with elevated privileges. | |
That is supposed to act as a friendly reminder that you haven't | |
given up the privileges yet, and marks the output of all commands | |
that ran with privileges appropriately. (If you don't like this, | |
you can easily turn it off via the --background= switch). | |
(emphasis mine) | |
deadbunny wrote 1 day ago: | |
I for one love to type out 13 extra characters to a 4 character | |
command to disable dumb choices by the developer. | |
On a more serious note, I wonder what random ASCII escape | |
sequences we can send. | |
Karellen wrote 15 hours 49 min ago: | |
> I for one love to type out 13 extra characters | |
FWIW, systemd is normally pretty good at providing autocomplete | |
suggestions, so even if you don't want to set up an alias | |
you'll probably just have to type `--b ` to set it. | |
> I wonder what random ASCII escape sequences we can send. | |
According to the man page source[0]: | |
> The color specified should be an ANSI X3.64 SGR background | |
color, i.e. strings such as `40`, `41`, â¦, `47`, `48;2;â¦`, | |
`48;5;â¦` | |
and a link to the relevant Wikipedia page[1]. Given systemd's | |
generally decent track record wrt defects and security issues, | |
and the simplicity of valid colour values, I expect there's a | |
fairly robust parameter verifier in there. | |
In fact, given the focus on starting the elevated command in a | |
highly controlled environment, I'd expect the colour codes to | |
be output to the originating terminal, not forwarded to the | |
secure pty. That way, the only thing malformed escapes can | |
affect is your own process, which you already have full control | |
over anyway. | |
(Happy to be shown if that's a mistaken expectation though.) | |
[0] [1] | |
[1]: https://github.com/systemd/systemd/blob/main/man/run0.... | |
[2]: https://en.wikipedia.org/wiki/ANSI_escape_code#SGR_(Se... | |
BenjiWiebe wrote 22 hours 5 min ago: | |
'alias' is your friend. | |
deadbunny wrote 13 hours 39 min ago: | |
I shouldn't need to alias behaviour that violates the | |
principle of least surprise on every single machine I need to | |
run elevated commands on. | |
shrimp_emoji wrote 12 hours 54 min ago: | |
Eh. | |
`alias grep='grep --color=auto'` | |
`alias ls='ls --color=auto'` | |
It's canon. | |
zamadatix wrote 1 day ago: | |
I think it's more that the default seems backwards than the lack | |
of ability to change it. | |
dsr_ wrote 1 day ago: | |
It's three things: | |
* here is a feature which we are defaulting to on | |
* there's no persistent config for it | |
* we know better than you do about your preferences | |
zamadatix wrote 1 day ago: | |
"Defaulting to on" is just a symlink to an existing binary so | |
that's not really much a problem. | |
gpm wrote 1 day ago: | |
A symlink to a binary that I'm going to pass a password to | |
seems like a security bug waiting to happen (just in the | |
manner that any complexity around privilege escalation is a | |
bad idea). | |
gh02t wrote 1 day ago: | |
It was a bit unclear to me from the thread, is there a persistent | |
configuration option for this? I like the idea of tinting the | |
terminal, but I also want to be able to turn it off with a global | |
config option rather than having to type out a --background flag | |
every invocation. | |
zamadatix wrote 1 day ago: | |
Aliasing the command as the command + your default arguments is | |
the easiest general solution to this kind of problem. I'm not | |
sure if there is a "systemd way" to permanently set it though. | |
tolciho wrote 1 day ago: | |
I accidentally compile color support out of st, or set | |
xterm*colorMode:false to avoid seeing the backside of a | |
unicorn randomly rubbed all over the terminal, on account of | |
git and other wares being bad at their inability to not spew | |
color codes. A sensible default would be to set no colors, in | |
the event that the colors are unreadable (due to | |
colorblindness, etc) or distracting, but that ship sailed. | |
Most of my vim config on RedHat linux was disabling wacky | |
vendorisms, and back when I used linux I did have a "special | |
terminal" for some NVIDIA installer that mandated colors to | |
be usable. Maybe the terminal title was set to Fisher-Price, | |
maybe not. | |
shrimp_emoji wrote 12 hours 49 min ago: | |
Dang. I wish I had the autism to bristle at colors. Think | |
about all the lost hours agonizing over themes! Not feeling | |
the agonizing tension between the fact that cool-retro-term | |
made your terminal into an awesome monochrome CRT but that | |
it's monochrome green so your syntax highlighting is all | |
messed up! | |
> back when I used linux | |
What do you use now? :0 BSD? Plan 9??? | |
gh02t wrote 1 day ago: | |
True, I was thinking a simple environment variable or systemd | |
configurable would be fine but I guess an alias is a good | |
idea. | |
kevincox wrote 1 day ago: | |
> One could say, "run0" is closer to behaviour of "ssh" than to "sudo", | |
in many ways. | |
This is an interesting offhand comment. You could implement a very | |
similar tool by SSHing to localhost. | |
TachyonicBytes wrote 1 day ago: | |
It's the usual way to make changes to a privileged file in Emacs; ssh | |
to localhost with root. | |
lanstin wrote 23 hours 2 min ago: | |
I like to have one of my tmux windows be a sudo session with emacs | |
running as root and mostly used to run emerge world or apt update | |
etc. also a window tailing all the logs. I havenât been on a | |
machine where more than one admin was logged in at the same time in | |
quite some time. | |
tristan957 wrote 1 day ago: | |
Why not use sudoedit? | |
terinjokes wrote 1 day ago: | |
'sudo' and 'doas' are inline connection methods in TRAMP, so no | |
need for SSH to localhost. Curious that systemd-run isn't already | |
supported, but I imagine that will quickly change. | |
m463 wrote 1 day ago: | |
I had to write an ssh client for an embedded system long ago. | |
Looking at the design, I found it to be sort of messy. | |
You could restrict commands ssh could invoke, but it didn't seem | |
super secure. | |
Also scp/sftp was not well designed. You basically had to give ssh | |
access to your system to allow a file to be copied, and there were no | |
real path restrictions. | |
I personally thought ssh could be much more robust in what you could | |
run and what you couldn't. And scp/sftp could have better filesystem | |
semantics so you could have more security in what you could access. | |
And I thought having a write-only scp would be really interesting, | |
sort of like a dropbox for people to send you files securely, but not | |
have to give someone ssh credentials to do it. And an anoymous | |
scp/sftp for distribution or a dropbox could have been really | |
interesting too. | |
__s wrote 13 hours 34 min ago: | |
You can restrict SSH commands by having it serve a restricted shell | |
instead of arbitrary shell. Like how there's games where you can | |
SSH into server to play | |
[1]: https://crawl.develz.org/wordpress/howto#connecting | |
CraigJPerry wrote 20 hours 6 min ago: | |
>> And I thought having a write-only scp would be really | |
interesting | |
I think you can achieve that at the file system level. At least, a | |
long long time ago I maintained a public server with exactly that | |
functionality. Iâve forgotten the details now but if I were | |
tasked with this today my first attempt would be add a sticky bit | |
like we do with /tmp: chmod +t dropbox/ | |
If you donât want to allow me to delete or overwrite my own files | |
I believe (but havenât tested) that chattr +a on the dropbox dir | |
would achieve that. | |
metalspoon wrote 1 day ago: | |
Well, yes, rsync to replace scp. Sftp's also regarded a hack anyway | |
imho. | |
The write-only scp intrigues me. I guess it's not hard to write a | |
program to do that. But, right, that's not easy with standard tools | |
only. The Linux file system was also not designed for that | |
(although it doesn't prohibit such software) I guess. | |
eru wrote 20 hours 24 min ago: | |
> The Linux file system was also not designed for that (although | |
it doesn't prohibit such software) I guess. | |
There's no 'the' Linux file system. There's plenty of file | |
system to choose from. | |
And, in fact, it would be relatively easy to write a write-only | |
filesystem with FUSE. ( [1] ) | |
[1]: https://en.wikipedia.org/wiki/Filesystem_in_Userspace | |
yegle wrote 1 day ago: | |
In my previous job, we set up a privileged account on a server with | |
shell set to `git-shell`, leave some shell scripts in $HOME, so that | |
we can do: | |
> ssh user@privileged-commands ./do-something | |
Arnavion wrote 1 day ago: | |
Technically `sudo -u` can switch to any user on the system while only | |
a limited few would be allowed as ssh targets. Even root might not be | |
allowed as an ssh target if `PermitRootLogin` is set to `no`, which I | |
do on all my systems. | |
fsckboy wrote 23 hours 44 min ago: | |
>Even root might not be allowed as an ssh target if | |
`PermitRootLogin` is set to `no`, which I do on all my systems. | |
would something like PermitRootLogin=localhost punch an enormous | |
hole in your intricate opsec? | |
jimbobthrowawy wrote 21 hours 42 min ago: | |
I've set up tor on some machines to forward ssh as a hidden | |
service for an easy to configure way to get past NAT before. That | |
shows up as a login from localhost. (could be configured | |
differently, with some extra work) | |
There's so ways to configure access to a system, each with | |
footguns I'm surely unaware of. | |
pmontra wrote 1 day ago: | |
I do use that a lot | |
sudo -H -u user bash | |
after I ssh into a server with my own account. That other user | |
might even be a no login account. | |
noinsight wrote 1 day ago: | |
You can just use `-i` instead of `bash`. (This method indeed | |
requires a shell configured, your method is needed with nologin.) | |
__s wrote 1 day ago: | |
Indeed, there was a blog by a redhat engineer doing that: | |
[1]: https://tim.siosm.fr/blog/2023/12/19/ssh-over-unix-socket | |
immibis wrote 1 day ago: | |
This will be great. We can finally deprecate sudo on systemd systems. | |
Then we should be able to deprecate PAM, setuid bit, etc. | |
Retr0id wrote 1 day ago: | |
Is removing setuid actually a win? I know it presents a security | |
risk, but it feels like we're not actually removing that attack | |
surface, just moving it around. | |
NekkoDroid wrote 1 day ago: | |
Well... that "attack surface" isn't new, its mostly just | |
repackaging systemd-run, which is just used to tell PID1 to launch | |
a new process. So in total the attack surface would be reduced by | |
removing sudo. | |
yjftsjthsd-h wrote 1 day ago: | |
I can see creating a system with zero setuid files, but I don't think | |
this reduces PAM use, does it? | |
segasaturn wrote 1 day ago: | |
This is very interesting, can somebody explain what this is and how | |
it's different from executing through sudo? The LWN post links back to | |
Lennart's Mastodon which in turn is a big pile of toots (ugh) in the | |
wrong order | |
sys_64738 wrote 1 day ago: | |
How long before humans are systemd compatible? | |
ezoe wrote 1 day ago: | |
I wonder what other existing programs Will Systemd attempt to replace | |
in the future. | |
My bet is /bin/sh, maybe they went further to replace the entire POSIX | |
utilities. | |
vbezhenar wrote 15 hours 10 min ago: | |
Hopefully glibc and coreutils! | |
rcxdude wrote 16 hours 51 min ago: | |
I mean, it already has replaced the shell in a lot of ways. Systemd | |
is basically the one reason why it's feasible to banish POSIX shells | |
to where they belong, albeit still not usually practical. | |
samgranieri wrote 1 day ago: | |
Letâs call it GNU/systemd/linux | |
yencabulator wrote 3 hours 13 min ago: | |
I think it's more that they're replacing the traditional GNU | |
programs with systemd. | |
That will result in systemd/Linux. | |
quectophoton wrote 1 day ago: | |
filesystemd, replacing ext4/btrfs/etc. | |
It will come with `filectl` for all your file operations, so you will | |
no longer need `cd`, `pwd`, `touch`, `rm`, `mkdir`, `cat`, `grep`, | |
`find`, etc. Instead you do everything through `filectl` commands. | |
This will deprecate many commands from GNU coreutils, which is a good | |
thing because replacing things is always good. | |
Then, since programs are just files, and filesystem will be part of | |
systemd, any program you want to use will obviously have to go | |
through systemd as well, meaning they will need to be a service unit | |
of type `oneshot`, because this way we keep everything well | |
integrated together. | |
Don't worry tho, you only write the unit files once and they work | |
forever. The only thing you need to remember is that, instead of | |
`cargo build` you'll need to use `filectl exec -u cargo build` | |
(`filectl exec -u` is only 3 words, so you don't have the right to | |
ever complain about this tiny little change). | |
Anyone who doesn't like these changes is stuck in the past. | |
LNK_ wrote 4 hours 7 min ago: | |
And one day you boot into the single mode and can't execute a file | |
because you you can't connect to systemd D-BUS error 0xDEADBEAF | |
contact your systemd admnistrator | |
woku wrote 13 hours 2 min ago: | |
> You will no longer need `cd`, `pwd`, `touch`, `rm`, `mkdir`, | |
`cat`, `grep`, `find`, etc. Instead you do everything through | |
`filectl` commands. | |
This is not as ridiculous as it sounds. Arguably, the file system | |
is more of an exception, because it is directly exposed by the | |
kernel. But, for example, to manage the files in a tar archive you | |
do everything with the `tar` command and to manage a git repository | |
you do everything with the `git` command. | |
jimbobthrowawy wrote 21 hours 35 min ago: | |
busyboxd? | |
imiric wrote 1 day ago: | |
> The only thing you need to remember is that, instead of `cargo | |
build` you'll need to use `filectl exec -u cargo build` | |
No, you forgot about `buildctl` which compiles any language into | |
systemd bytecode, that runs on the systemd VM. At long last, write | |
once, run anywhere! | |
foresto wrote 1 day ago: | |
> instead of `cargo build` you'll need to use `filectl exec -u | |
cargo build` | |
You joke, but I already have to do this with lxc commands, and the | |
systemd-compatible version of those commands is even longer than | |
you imagined. See my other comment for details. | |
anthk wrote 1 day ago: | |
Guix will reimplement POSIX utils and extras with tools written in | |
Gule. | |
smegger001 wrote 1 day ago: | |
Please say this is a joke | |
anthk wrote 1 day ago: | |
[1] It wouldn't be a bad idea. Also, Guile's JIT could be | |
interesting there. | |
Also, a shell with a live REPL instead of failing on errors can | |
be pretty interesting. | |
[1]: https://nlnet.nl/project/Gash/ | |
zarzavat wrote 20 hours 29 min ago: | |
âgashâ oh my, what a name. Do you think they know? | |
gpderetta wrote 1 day ago: | |
Does systemd read email yet? | |
mehdix wrote 1 day ago: | |
Lennart's toots suggest they are replacing a complex SUID binary with | |
an already existing component (systemd-run) with better workflow | |
(service manager handling the elevated context), which sounds like a | |
sane move to me. | |
frafra wrote 1 day ago: | |
This is not new functionality: | |
"Thereâs a new tool in systemd, called ârun0â. Or actually, | |
itâs not a new tool, itâs actually the long-existing tool | |
âsystemd-runâ, but when invoked under the ârun0â name (via… | |
symlink)". | |
systemd-run is very useful to run tasks with specific cgroups settings, | |
or at a specific time. It asks for password whenever needed. | |
kbar13 wrote 1 day ago: | |
systemd has been a net positive for the linux ecosystem. remember when | |
you had to write bash scripts to start, stop, restart services and | |
handle any other signals you want to send it? nowadays it's a unit file | |
(basically just an ini file) away with relatively straightforward API. | |
and you can actually declare startup dependencies and other useful | |
relationships past just "prepend a number signifying when it should run | |
globally to the front of the filename". it's provided an extensible | |
platform with which higher level orchestration frameworks like ansible | |
/ ignition can easily templatize services or other system | |
configuration. | |
since the beginning of systemd people have moaned about how complex it | |
is and how we're reinventing the wheel. yet time and time again the | |
people actually working on the project show that the solution they've | |
come up with is the result of the problem they're facing on a daily | |
basis. it's quite annoying that the armchair linux experts complain | |
about how "lol systemd is so stupid for reinventing the wheel, give me | |
my shell scripts back", maybe think about whether or not you have a | |
legitimate issue not being addressed by the solution proposed or if you | |
are just getting rage baited by a headline. | |
nextaccountic wrote 1 day ago: | |
> systemd has been a net positive for the linux ecosystem. remember | |
when you had to write bash scripts to start, stop, restart services | |
and handle any other signals you want to send it? | |
Systemd was meant to replace Ubuntu's upstart, not sysv init. And it | |
indeed systemd was better designed than upstart. | |
Sysv init is a horrendous hack. People should NOT use that. Upstart | |
had limitations but is okay, and certainly much better than sysv | |
init. Systemd is okay too (but has much more features). | |
Also as an historical note, both upstart and system was inspired by | |
Apple's launchd. | |
NixOS was an early adopter of upstart but it later migrated to | |
systemd (alongside Ubuntu itself) | |
foresto wrote 1 day ago: | |
> systemd has been a net positive for the linux ecosystem. | |
You're presuming to speak for an awful lot of people there, on a | |
topic that would be difficult to measure. | |
> since the beginning of systemd people have moaned | |
> it's quite annoying that the armchair linux experts complain | |
Now you're overgeneralizing, and doing so in a dismissive and | |
patronizing way. | |
Here are a few examples of problems I have with systemd: | |
System shutdown/reboot is now unreliable. Sometimes it will be just | |
as quick as it was before systemd arrived, but other times, systemd | |
will decide that something isn't to its liking, and block shutdown | |
for somewhere between 30 seconds and 10 minutes, waiting for | |
something that will never happen. The thing in question might be | |
different from one session to the next, and from one systemd version | |
to the next; I can spend hours or days tracking down the | |
process/mount/service in question and finding a workaround, only to | |
have systemd hang on something else the next day. It offers no manual | |
skip option, so unless I happen to be working on a host with | |
systemd's timeouts reconfigured to reduce this problem, I'm stuck | |
with either forcing a power-off or having my time wasted. | |
Something about systemd's meddling with cgroups broke the lxc control | |
commands a few years back. To work around the problem, I have to | |
replace every such command I use with something like `systemd-run | |
--quiet --user --scope --property=Delegate=yes `. That's a PITA that | |
I'm unlikely to ever remember (or want to type) so I effectively | |
cannot manage containers interactively without helper scripts any | |
more. It's also a new systemd dependency, so those helper scripts now | |
also need checks for cgroup version and systemd presence, and a | |
different code path depending on the result. Making matters worse, | |
that systemd-run command occasionally fails even when I do everything | |
"right". What was once simple and easy is now complex and unreliable. | |
At some point, Lennart unilaterally decided that all machines | |
accessed over a network must have a domain name. Subsequently, every | |
machine running a distro that had migrated to systemd-resolved was | |
suddenly unable to resolve its hostname-only peers on the LAN, | |
despite the DNS server handling them just fine. Finding the problem, | |
figuring out the cause, and reconfiguring around it wasn't the end of | |
the world, but it did waste more of my time. Repeating that | |
experience once or twice more when systemd behavior changed again and | |
again eventually drove me to a policy of ripping out systemd-resolved | |
entirely on any new installation. (Which, of course, takes more | |
time.) I think this behavior may have been rolled back by now, but | |
sadly, I'll never get my time back. | |
There are more examples, but I'm tired of re-living them and don't | |
really want to write a book. I hope these few are enough to convey my | |
point: | |
Systemd has been a net negative in my experience. It has made my life | |
markedly worse, without bringing anything I needed. Based on | |
conversations, comments, and bug reports I've seen over the years, I | |
get the impression that many others have had a similar experience, | |
but don't bother speaking up about it any more, because they're tired | |
of being dismissed, ignored, or shouted down, just as I am. | |
I would welcome a reliable, minimal, non-invasive, dependency-based | |
init. Systemd is not it. | |
Nextgrid wrote 2 hours 27 min ago: | |
When it comes to the shutdown issue, I'd argue this is a | |
side-effect of systemd bringing some consistency and correctness to | |
what used to be the wild west, and is highlighting some issue that | |
was before overlooked. | |
Granted, in a lot of cases the issue probably wasn't a big deal | |
(the system is being shut down, the user is already logged out, do | |
you really care that a system background process is being shut down | |
cleanly?) but from systemd's perspective there's no difference | |
between that and an actually business-critical process that should | |
absolutely be allowed to terminate cleanly before unmounting the | |
filesystem and powering off the machine. | |
evertedsphere wrote 15 hours 50 min ago: | |
> It offers no manual skip option | |
ctrl-alt-del skips iirc? | |
imtringued wrote 16 hours 22 min ago: | |
Systems isn't blocking the shutdown. Systems is being blocked by a | |
service. Since you are saying that you can't track down the exact | |
service, you must be using a container runtime like docker or LXC | |
which is not transmitting the kill signal properly to the container | |
to shut it down. The container itself then keeps running for | |
whatever reason. This entirely depends on your particular setup and | |
has very little to do with systemd. | |
foresto wrote 15 hours 41 min ago: | |
> Since you are saying that you can't track down the exact | |
service, | |
That is not what I said. | |
bitwize wrote 1 day ago: | |
I don't resent systemd for existing, but I don't want to be forced to | |
accept Lennart's shitty design decisions and it's clear he wants me | |
to be since he successfully agitated for other critical components to | |
hard depend on it. I want the option of opting out, which Lennart | |
would deny me if he could. | |
At the end of the day, I just run Void (or MX Linux if I want | |
something more Debian-flavored) and get on with my life. | |
aerique wrote 14 hours 17 min ago: | |
Void Linux and now Guix have been a godsend. | |
aftbit wrote 1 day ago: | |
Ah yes I remember back when you just put the system hostname in | |
/etc/hostname. Now we have hostnamed! | |
egorfine wrote 1 day ago: | |
Which is now borderline impossible to tame. Google "change hostname | |
ubuntu" and take a look at the results and comments. | |
pcthrowaway wrote 20 hours 7 min ago: | |
I'm still trying to figure out whether I like nftables more than | |
iptables. Both are pretty complex to manage IIRC (I've only | |
touched nftables a couple of times though, and not recently) | |
aerique wrote 14 hours 18 min ago: | |
Well, it has "NFT" in the name so it must be good! | |
paulddraper wrote 1 day ago: | |
100% | |
Systemd unit files make Linux feel like a rational OS. | |
slackfan wrote 1 day ago: | |
Only if your marker for a rational OS is NT. | |
delta_p_delta_x wrote 1 day ago: | |
Not the parent commenter. Windows has a lot of rubbish user-level | |
interaction which belie how good an OS NT really is. Anyone who | |
blindly disses it because 'Windoze' and 'M$ bad' is not really | |
worthy of any attention whatsoever. | |
slackfan wrote 1 day ago: | |
NT isn't terrible with some very well designed systems, that is | |
quite true. It is however good for a completely different list | |
of reasons that *nix is. Trying to conflate the two is a | |
pottering's errand. | |
agilob wrote 1 day ago: | |
> remember when you had to write bash scripts to start, stop, restart | |
services | |
This was a really big pain, yes, but I also remember how I could | |
`tail -f *.logs`. I remember how I didn't need to remember about | |
`--no-pager` and `--follow`. I knew where the files were, what they | |
were called. I remember how I didn't have to google how to find logs | |
between 10 days ago and 4 days ago, because the logs would be in a | |
.tar created by logrotate with a date in the filename. | |
The init system was probably peak of systemd, after that they started | |
reinveting things in a more complicated way. Do we really need | |
journald, systemd-boot, machinectl, systemd-networkd, sd-bus, | |
systemd-resolved, systemd-nspawn? Do people actually use it all? Are | |
there any metrics to show how many systems have it installed and in | |
use? | |
SoftTalker wrote 23 hours 30 min ago: | |
Those old init scripts were pretty boilerplate and not that hard to | |
write. And in the case of OpenBSD (and maybe other BSDs?) the | |
scripts for /etc/rc.d are usually just a few lines. | |
With the traditional init system I knew what was going on, and if I | |
didn't, find and grep were your friends. With systemd I'm googling | |
everything every time. The systemctl man page is over 1,100 lines. | |
OpenBSD's rcctl man page is 119 lines. | |
I'm sure there are use cases for systemd but for running a server | |
that provides a single or a handful of services, it seems like | |
complete overkill. | |
ranger207 wrote 1 day ago: | |
I remember, and sometimes still have to deal with, programs that | |
_didn't_ dump their logs in /var/log, forcing me to figure out | |
where the log are in the first place | |
rezonant wrote 1 day ago: | |
> This was a really big pain, yes, but I also remember how I could | |
`tail -f *.logs`. | |
Others point out that journalctl supports `-f` and `-n` for | |
determining how much journal to return, but for me what's great | |
about journalctl is that I do not need to know where the program is | |
logging to, how it rotates logs (or how it doesn't), or anything | |
else. The program does not need special permissions to a log | |
location in /var/log or /usr/var/log or ~/... or anything else, it | |
just outputs using stdout and it gets captured. When I want to look | |
at logs, I just use the same moniker that I use to control the | |
service: its unit name. It is so incredibly nice- I do not want to | |
go back to the bad old days of spelunking through /var/log and | |
friends. | |
> --no-pager | |
To be clear, if you pipe journalctl somewhere, it will | |
automatically skip the pager and just work. `--no-pager` is most | |
useful for when you want to print some unpiped content in an | |
automated script to avoid having a non-existent user exit the | |
pager. | |
sunshowers wrote 1 day ago: | |
I've recently become a fan of the `-x` flag to journalctl, which | |
adds additional context to log entries and even suggests | |
remediations at times. I've identified and fixed several issues on | |
my Linux systems that way. Kind of hard to get that with tail -f! | |
aeonik wrote 1 day ago: | |
How does it work? Can I pipe non-journald logs into the -x flag | |
to take advantage of this lookup? | |
dumpsterdiver wrote 1 day ago: | |
My goto is journalctl -xf. Best of both worlds :) | |
rezonant wrote 1 day ago: | |
Ooh nice. What are some examples of things it will catch? | |
jordemort wrote 1 day ago: | |
systemd-nspawn is actually pretty great, and is mostly just a tool | |
that exposes functionality that systemd already needs for other | |
reasons. IIRC it was originally developed to aid in testing systemd | |
itself, and was initially shipped as an unsupported extra in case | |
other people found it useful. | |
systemd-resolved is the only way I've ever been able to get dockerd | |
to play nice with Tailscale DNS; it's also the best way that I've | |
found to get a system to pick different upstream DNS servers | |
depending on domain. The alternative is hand-rolling it with | |
dnsmasq or something similar. | |
I admit I haven't really seen a huge advantage to using | |
systemd-networkd over NetworkManager yet, but for servers with | |
relatively static network configurations, I greatly prefer | |
systemd-networkd over any of the various implementations of | |
ifupdown. | |
lolinder wrote 1 day ago: | |
> I could `tail -f *.logs`. I remember how I didn't need to | |
remember about `--no-pager` and `--follow`. | |
journalctl supports -f, which by your own account you were already | |
using for tail, so I'm not clear what's worse there. | |
> I remember how I didn't have to google how to find logs between | |
10 days ago and 4 days ago, because the logs would be in a .tar | |
created by logrotate with a date in the filename. | |
My memory of this time was that every single application had its | |
own unique method of handling logs and its own unique location for | |
storing them. So sure, once you found the logs you didn't have to | |
Google how to find the relevant dates if the application is using | |
logrotate as you describe, but finding the logs in the first place | |
was always a challenge. Systemd is nice in that it provides a | |
single place where all logs go and a single interface for | |
navigating them. | |
hmmm-i-wonder wrote 10 hours 1 min ago: | |
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 millions of other users for | |
years/decades with something that... also works... but | |
differently. Now to accomplish the _SAME_ outcome without any | |
personal benefit I have to re-learn their new and usually | |
opinionated way. | |
There was a time I could log into a system, find logs, parse | |
dates and do everything in these discussions reletave to logs, | |
rotation. Regardless of service because the standards were close | |
enough and the basic tooling (tail/find/tar/grep/awk etc.) worked | |
everywhere always, and you never had to google even if the | |
service was one you never worked on before. | |
For systemd its the opposite, its almost a guarantee you have to | |
google something along the line when interacting with new systems | |
and services. And as soon as their newly enforced opinions and | |
way of doing things is getting comfortable they go and replace | |
something else that was also working... perfectly fine. | |
If it actively solved problems for the majority of users we | |
wouldn't hate it so much. Instead it requires more mental | |
overhead than anything other than XORG to deal with and | |
constantly manage than anything else in the linux ecosystem. | |
SoftTalker wrote 23 hours 26 min ago: | |
Not my memory at all. In almost all cases the logs were in | |
/var/log and written by syslog. Unless the whole service was in a | |
chroot directory, or the program was written by an amateur who | |
didn't follow logging conventions. | |
citrin_ru wrote 1 day ago: | |
'journalctl -u service -f' takes many seconds to start showing | |
logs (even with 4GB journal size limit which not that much). | |
'tail -f /var/log/service' works without a noticeable delay (be | |
it 1kb or 100Gb log file). For me it's a huge regression. | |
rezonant wrote 1 day ago: | |
While I'm very pro journalctl, this is very true. They should | |
put some work into the initial read performance on big | |
journals. | |
Asmod4n wrote 1 day ago: | |
Oh the joy it is to have a corrupted log file which the program | |
that wrote it refuses to even read. | |
Once you deal with that youâll realize journald is just in the | |
way and needs to be modified to output a human readable log by | |
default. | |
cduzz wrote 1 day ago: | |
I appreciate that someone's invented shoes you inflate and snap. | |
I can see some advantages. | |
That said, when I'm in a hurry and going to do a thing that I've | |
been doing every day of my life, I'm really not a big fan of | |
having to stop what I'm doing and reexamine a tool I've used all | |
my life to figure out how to use it. I learned this stuff | |
decades ago and I'm not anxious to relearn how to do it for a | |
fractional improvement, and I'm not even really 100% sure that | |
this new "inflate and snap" shoe model is actually an | |
improvement, except for very specific use cases. | |
acdha wrote 1 day ago: | |
Donât think of it as relearning a tool, think of it as | |
learning one tool which works for everything. You no longer | |
have to implement your own log rotation, compression, etc. or | |
work out which configuration each program needs to do that in | |
the manner you expect â for example, âis it safe to rotate | |
a log file?â requires you to know implementation details on | |
each program. | |
llm_trw wrote 22 hours 33 min ago: | |
>think of it as learning one tool which works for everything. | |
For how long? | |
I've been around for decades at this point with people | |
telling me how the newest and greatest thing will obsolete | |
everything that came before it. | |
The best way to look through logs is still to materialize | |
them in as text in a files hierarchy and use find with grep | |
to look for issues. | |
acdha wrote 15 hours 47 min ago: | |
Iâve been doing this for decades, too, but I donât miss | |
having to deal with everyone inventing multiple log | |
hierarchies, different rotation conventions, compression | |
strategies, etc. not to mention all of the other things | |
which systemd removed from daily toil around process | |
management. | |
olddustytrail wrote 20 hours 3 min ago: | |
> For how long? | |
Debian switched to systemd about 12 years ago, so at least | |
that long. | |
cduzz wrote 18 hours 12 min ago: | |
A quick google indicates that it was made default in | |
debian 8 in 2015, which is 9 years ago, not 12. | |
Perhaps it was available prior to then, but so were | |
daemontools, upstart, and probably a variety of other | |
alternatives. | |
olddustytrail wrote 9 hours 10 min ago: | |
Yes, you're right. I saw when it was added not when it | |
became the default. Still 9 years suggests it's not | |
going to disappear overnight! | |
acdha wrote 9 hours 30 min ago: | |
One thing to remember is that a lot of people use the | |
testing distribution so they would have seen it before | |
the Debian 8 release changed the default. The debate in | |
the community took ages but one factor in concluding it | |
was that people were using it for years without it | |
being anything like the more hyperbolic predictions | |
some opponents made. | |
llm_trw wrote 19 hours 28 min ago: | |
Find came out in 1974. | |
cogman10 wrote 1 day ago: | |
I think my biggest gripe with journalctl is (and this may just be | |
because I'm novice at using it) that discovering what sort of | |
logs are on the system feels a lot more complex. | |
With regular logs, I can go to /var/log, ls the dir, and get a | |
nice list of what's being logged. There will be, for example, an | |
`apache.log` file that has all the logs relevant to apache. | |
tapoxi wrote 1 day ago: | |
It's just journalctl -u apache -f, assuming your distribution | |
calls the unit file "apache", and the last few messages of the | |
logfile appear with systemctl status apache | |
And you don't need to worry about "is this service rotating | |
logs appropriately?" | |
cogman10 wrote 1 day ago: | |
The important thing for me at least isn't he `-u apache` but | |
rather knowing that `apache` exists as one of the installed | |
services on this box. | |
In the old ways, that was apparent because of the presence of | |
the log file. | |
Granted, this isn't the problem it used to be for us, | |
however, it would come up because we'd have our services | |
named things like `foo-ws` and knowing that `foo-ws` existed | |
on a given box might be tricky were it not for the log files. | |
pcthrowaway wrote 20 hours 19 min ago: | |
`systemctl list-unit-files` is too difficult? | |
kbar13 wrote 1 day ago: | |
honestly that's such a niche problem to have that i dont | |
think it's worth throwing the baby out with the bathwater. | |
anyways you shouldn't be discovering installed services by | |
logfile presence, it should be something like querying your | |
package manager. | |
rixed wrote 21 hours 14 min ago: | |
I wouldn't say it's a niche problem. I also miss being | |
able to go to /var/log and see instantly what's going on. | |
There should be a command like "journalctl --top" that | |
would list all logging services with amount of logs, | |
oldest and latest log times, and last few lines of each, | |
to improve that experience. Maybe there is already a way | |
to do something similar? | |
tadfisher wrote 1 day ago: | |
journalctl -f -u | |
Shows you all installed units if you have working shell | |
completion, or 'a' gets you all units starting with 'a', | |
etc. | |
vbezhenar wrote 15 hours 6 min ago: | |
With `ls -l` I can see file modification dates. How do I | |
do it with journalctl? And why do I need to that that in | |
the first place? | |
Journald would be perfect if I didn't have to know a | |
thing about it. Work in background, move stuff from | |
stdin/stdout to /var/log/journald/service.log, move old | |
stuff in | |
/var/log/journald/archive/service/2024-04/15.log.gz. I'd | |
be happy. Why do I need this cryptic CLI I don't | |
understand. It brings nothing but pain. | |
foxhill wrote 16 hours 26 min ago: | |
correct me if iâm wrong, but i believe the point that | |
is trying to be made is; | |
a system user/admin has an intuition about files. saying | |
that âjournalctl -f -uâ (fu, indeed :) and whatever | |
else is inherently undiscoverable, and is a.. basically | |
orthogonal mechanism for handling what should be a simple | |
task. i.e., viewing some logs. itâs far easier to | |
compose and extend from files (what if i only care about | |
the mtime of the log, for instance), than this. | |
look, i think systemd isnât.. terrible. i also think | |
itâs suffered a bit of complexity fetishisation, and it | |
seems as though that this resulting complexity may have | |
become invisible to you. | |
run0 doesnât seem like a bad idea. but i am wincing a | |
bit at the thought of unrestricted javascript determining | |
access control. | |
amaterasu wrote 1 day ago: | |
In which shell? | |
alright2565 wrote 1 day ago: | |
bash & zsh are supported by upstream: | |
[1]: https://github.com/systemd/systemd/tree/main/s... | |
ac29 wrote 1 day ago: | |
Works in fish, I'll have to remember that one | |
tapoxi wrote 1 day ago: | |
I mean "systemctl status" shows all services and their | |
hierarchy, there's also "systemctl list-unit-files" if you | |
want to see things that aren't part of the current target | |
(runlevel). | |
It's much easier in the systemd world to see the state of | |
the system, the state of the service, and the logs of a | |
service because it enforces this consistency. | |
cogman10 wrote 1 day ago: | |
Ah, good to know. I figured it might be the case that I | |
just needed to RTFM. | |
saghm wrote 1 day ago: | |
> journalctl supports -f, which by your own account you were | |
already using for tail, so I'm not clear what's worse there | |
Yeah, this is a bit of an odd complaint. If I were this bothered | |
by having to type those, I'd just make an alias to "journalctl | |
--follow --nopager"` and would have forgotten about it years ago. | |
mdaniel wrote 1 day ago: | |
> I'd just make an alias to "journalctl --follow --nopager"` | |
and would have forgotten about it years ago. | |
You sure would have forgotten about it when you tried to get | |
onto another machine without the magic set of aliases | |
I am also prepared for someone to chime in that "log egress | |
tools exist" to move up the Maslow's Hierarchy of Log Needs | |
stoperaticless wrote 1 day ago: | |
Never tried it, but if the complainer wrote: tail -f *.logs | |
Which involves globâing. I assume it allows to monitor | |
several services at the same time. | |
Can systemd do that? | |
_flux wrote 1 day ago: | |
It's the basic function what journalctl -f does by default: | |
follow the global log all jobs write into. -u etc are for | |
filtering that. | |
tapoxi wrote 1 day ago: | |
Yes, journalctl -u postgres -u redis -f etc | |
mintplant wrote 1 day ago: | |
Or just `journalctl -f` to follow all logs. | |
hughesjj wrote 1 day ago: | |
My 2c, I definitely prefer systemd boot+networkd, fine with | |
journald, don't use the others enough to have an opinion. | |
iforgotpassword wrote 1 day ago: | |
Same. Init system is awesome, love .ini files, networkd is as | |
simple as it can be, journald is fine. Love systemd-nspawn for | |
simple containers as it feels more lightweight than docker. | |
Especially for quick one-offs where I don't need isolated | |
networking you basically have chroot on steroids with | |
"systemd-nspawn -D /path/to/fstree". | |
superb_dev wrote 1 day ago: | |
The follow argument is identical to tail `-f`. | |
`sudo journalctl -f -u ` | |
rangerelf wrote 1 day ago: | |
And what would be the equivalent to, "Oh, I don´t know the name | |
of the log for this process I can see in 'ps aux', let me cd into | |
/var/log and see what filenames I can find ... or grep everything | |
until I can find a couple of words that make some sense so I can | |
keep digging further"? | |
The lack of explorability in journalctl, the "need" to keep | |
everything locked behind their own flavor of tools and magic file | |
types, is what makes the rest of us abhor them. | |
JoshTriplett wrote 1 day ago: | |
> Oh, I don´t know the name of the log for this process I can | |
see in 'ps aux', | |
With services using journald, there's no "name of the log" | |
because everything's in the journal, so that part isn't a | |
problem. Rather than "is this in auth.log or syslog or | |
thisservice.log", it'll always be in the journal. | |
> let me cd into /var/log and see what filenames I can find | |
You can filter journal entries by unit (-u) or by service | |
identifier (-t). Often, though, I find it really useful to be | |
able to see the adjacent entries from other services at the | |
same time, since that can give some indication of what's | |
happening on the system that caused an issue. | |
> or grep everything until I can find a couple of words that | |
make some sense so I can keep digging further | |
journalctl --grep, or more conveniently, journalctl and then / | |
to search. | |
> The lack of explorability in journalctl | |
It's explorable by dozens of different axes, and if all of | |
those aren't sufficient, you always can get the whole thing as | |
text and run any command you like on it, or get it in | |
structured form and do structured queries on it. | |
rcxdude wrote 1 day ago: | |
systemctl status will show you the unit and helpfully the last | |
few lines of log from it. Journalctl -u will then show you the | |
full logs | |
sunshowers wrote 1 day ago: | |
You do have to learn a few new things, yes. But it's not too | |
difficult. We all have to learn new things sometimes. | |
I spent around 15 minutes a few weeks ago learning how to do a | |
few things with journalctl, and I came away from it with a | |
great appreciation for its power. | |
ciupicri wrote 1 day ago: | |
# journalctl -f _PID=${your_pid} # option 1 | |
# systemctl status ${your_pid} # option 2 | |
[1] | |
[1]: https://www.freedesktop.org/software/systemd/man/lates... | |
[2]: https://www.freedesktop.org/software/systemd/man/lates... | |
Brian_K_White wrote 1 day ago: | |
These absolutely SUCK as answers to that question. They | |
entirely miss the point. They provide a specific answer to a | |
general problem. | |
The problem with systemnd is it assumes that it's possible | |
for all needs to be predicted and accounted for ahead of | |
time. While "look around at directories and files, and grep | |
within them" works after the fact without any special | |
knowledge or tools. The person who wrote the log file did not | |
need to know how someone will maybe try to access it 23 years | |
later on a different OS. It's just a regular file that can be | |
read by anything over any kind of channel on any os. The | |
person finding themselves needing to read the file does not | |
need to have any particular command installed, or | |
installable, or runnable. It does not require the happy path | |
in order to work. | |
I have a joke I always say, often self-deprecating making fun | |
of my own self for the way I do things sometimes, but also | |
when I'm trying to commiserate with a customer so they don't | |
feel intimidated by "the expert" or "the engineer": "37 easy | |
steps!" | |
Every answer that starts with "it's simple, just journalctl | |
..." is FUCKING 37 easy steps. The very name of the program | |
itself is a trainwreck. journalctl... it takes me 18 seconds | |
just to type it. | |
systemd is great for managing exquisitely washed masses of | |
drone vms. It's utter and complete shit for direct | |
administration, operation, development, debugging, | |
flexibility, or custom integrations. | |
rcxdude wrote 17 hours 4 min ago: | |
It's way better than the previous status quo: now, more or | |
less whatever distro I'm on, there's one command which | |
answers that question directly, not a process of guessing | |
how this system happens to be set up. You can guess and | |
grep through most any kind of problem, but I don't see why | |
anyone would want to do it as anything but a last resort, | |
and to me that fits '37 easy steps' far more than the 1 | |
consistent step in these replies (notice how none of them | |
say 'oh, but on debian...'?). | |
superb_dev wrote 22 hours 46 min ago: | |
I didnât answer the general question because I donât | |
care, I have no dog in this fight. Im just happy to provide | |
information. | |
I like systemd and have found it extremely useful. If it | |
doesnât fill a need for you then use something else. | |
sgarland wrote 1 day ago: | |
Agreed. Iâve tried to get used to it on Debian 12 for | |
personal VMs. I just canât. I donât care. grep and awk | |
are always going to be available, and I know how to use | |
them. | |
robertlagrant wrote 1 day ago: | |
> These absolutely SUCK as answers to that question. They | |
entirely miss the point. They provide a specific answer to | |
a general problem. | |
No they don't. They are good answers. If you want answers | |
to a more general problem, then ask. This is not an emotive | |
topic. | |
Brian_K_White wrote 1 day ago: | |
They may be correct answers, in that they accomplish a | |
task. | |
They suck in that the proposed method for accomplishing | |
the task is a suck-ass downgrade from the previous ways | |
the new way proposes to displace. | |
I beg to differ about emotive, because absolutely the | |
other side of this fence behaves every bit as butt-hurt | |
when challenged as I just did. You yourself just said | |
these crappy commands were good, as a purely unfounded | |
assertion. They are great because you just say they are | |
great. That is even less objective than my rant. I at | |
least explained what exactly I find so bad. Tell me more | |
about not emotive. | |
sunshowers wrote 1 day ago: | |
To be clear -- you can just dump out all the logs to | |
text and then use your standard grep toolkit on them. | |
You can also dump them out to JSON, and use jq on them | |
-- something you can't do with text logs on disk. | |
And as far as learning the options goes, learning the | |
basics of systemd and journalctl is much easier than | |
learning how to, say, use a source control system | |
effectively. | |
(And it's definitely worth trying out new source | |
control systems -- for example, I think most people | |
should at least check out Jujutsu, and many people are | |
going to like it more than Git. As simple as Jujutsu is | |
to use, learning it takes a lot longer than learning | |
journalctl.) | |
robertlagrant wrote 1 day ago: | |
> You yourself just said these crappy commands were | |
good, as a purely unfounded assertion. They are great | |
because you just say they are great. That is even less | |
objective than my rant. I at least explained what | |
exactly I find so bad. Tell me more about not emotive. | |
Very well: I didn't say the commands were good or | |
great. If you attempt a little objectivity you'll see | |
it. | |
Brian_K_White wrote 1 day ago: | |
If you attempt a little objectivity, you will see | |
that addressing the answers (vs the commands) was in | |
my first response. | |
Before even going into the nature of the commands, I | |
said that the answer does not match the question. The | |
answers addressed details, while the details in the | |
question were merely examples. | |
Missing the point is actually merely one of the at | |
least two dimensions along which the answers suck. | |
Thank you for reminding me about that. | |
robertlagrant wrote 1 day ago: | |
> The answers addressed details, while the details | |
in the question were merely examples. | |
No, the answers addressed the two scenarios in the | |
question. That's why they don't "SUCK". They are | |
good answers to the question as asked, and not the | |
question as you dreamed it. If you spent ten words | |
on asking the question of your dreams, rather than | |
having a go at people for not answering it | |
(whatever it is), you might have an answer. | |
superb_dev wrote 1 day ago: | |
Well `-u` refers to the unit file, so I would start with `sudo | |
systemctl status` which lists the status of active unit files. | |
I bet I could find the unit name I'm looking for there. If not, | |
then `sudo systemctl list-units` should have it. (and you can | |
grep the output of both) | |
Systemd and Journald are less opaque than I used to think. Even | |
if you don't want to learn the commands, all of its unit files | |
(and the relationships between them) are available through the | |
filesystem. Most of your unit files will be in | |
`/etc/systemd/system`, and the active relationships between | |
units are expressed through soft links. | |
ramses0 wrote 1 day ago: | |
systemctl does not have the Unix nature. | |
aeonik wrote 1 day ago: | |
How would you exclude certain units from your logs? Let's say | |
that Auditd is spamming your logs, and you just want to | |
exclude those? | |
Can you filter on search? How do you prevent applications | |
from writing to Systemd at all? | |
superb_dev wrote 22 hours 52 min ago: | |
I would start with `man systemd`, or maybe `journalctl | |
âhelp`. | |
If you donât want a service to log to systemd, then | |
donât run it in systemd? | |
pcthrowaway wrote 20 hours 14 min ago: | |
I think you can also configure the journal per unit | |
right? Don't remember how exactly, at the very least you | |
can stream logs to a different system. | |
There are also services which will just use their own | |
logging convention for some reason. Honestly it's easier | |
just to go with journalctl for everything you can. | |
iforgotpassword wrote 1 day ago: | |
Huh, isn't grepping journalctl output pretty much the same? It | |
even prefixes messages by the binary name. | |
mdaniel wrote 1 day ago: | |
Pedantically, they're the unit name which only sometimes | |
matches the binary name | |
rezonant wrote 1 day ago: | |
Actually no, they are prefixed by the binary name and the | |
PID number. Technically they are prefixed with: ` []`. | |
You can then use `systemctl status ` to identify the unit | |
if you need to. | |
I would imagine this is configurable, and this might be the | |
configuration chosen by my distribution (since I have not | |
changed it myself). It would actually be nice to show the | |
unit name instead of the binary/PID combination, though not | |
strictly necessary. | |
EDIT: Ooh, systemd 239 adds `journalctl -o with-unit` to do | |
this exact thing. There are lots of other formats you can | |
choose from as well. | |
EDIT 2: Unfortunately there's no way to set this as | |
default, you must use `-o with-unit` each time or set up a | |
shell alias :-\ | |
esoterae wrote 1 day ago: | |
No, it hasn't. | |
You forget, the reason systemd was originally rationalized for its | |
insertion into our trees was "boot times are too slow". Its | |
chameleon-like nature and ability to solve the hastily described | |
problem du jour seems to be its only consistently touted feature. | |
Bash scripts that start processes are ephemeral. If it's signal | |
handling you want, that was your program's problem. Either that or | |
your program didn't fork itself, which is a fish of an entirely | |
different feather. | |
And now we have this sprawling mess of complexity and headache. | |
riddley wrote 1 day ago: | |
Same thing is happening with Wayland. It reduces features adds | |
complexity and solves no new problems but here it comes. | |
roenxi wrote 1 day ago: | |
Wayland was a mis-fire in terms of user friendliness for the | |
first decade or so. But it is still a big step up from the mess | |
that was a typical xserver back in 2010. | |
> It reduces features adds complexity... | |
The irony here is Wayland is part of a huge effort to decomplex | |
an xserver into component parts. A really commendable initiative; | |
the path forward while maintaining the X protocol probably was | |
impractically hairy. | |
The Wayland protocol design had some glaring flaws, but saying | |
that it adds complexity is unfair. It oversimplified; it would | |
have benefited from some flexibility in providing a standard | |
mechanism to let people inspect the buffers graphics buffers to | |
be composited. | |
themerone wrote 1 day ago: | |
How is Wayland more complex than X? | |
j16sdiz wrote 19 hours 9 min ago: | |
Wayland by itself is simplier -- it is done by "outsourcing" | |
everything a window system should do to the window manager. | |
There is where the complexity kicks in. | |
gmueckl wrote 1 day ago: | |
The resulting wayland environments are more complex because | |
wayland itself refuses to define/include features that desktop | |
systems are expected to have. This results in a sprawling mess | |
of competing and incompatible interfaces for those gaps that | |
other parts of the implementations (desktop environments) now | |
have to compensate for by including multiple implementations of | |
the same thing based on all these different interfaces. | |
imtringued wrote 16 hours 30 min ago: | |
Stop using the wrong words. You're saying Wayland is too | |
simple and feature incomplete. | |
ranger_danger wrote 1 day ago: | |
> systemd has been a net positive for the linux ecosystem | |
I guess that depends on whether or not you consider the great number | |
of CVEs caused by it don't matter enough. | |
SixDouble5321 wrote 1 day ago: | |
Systemd isn't just one thing lol | |
xolve wrote 1 day ago: | |
Its refreshing to see that just hate systemd because "its not UNIX | |
way" is not anymore. I see better discussions under this post and in | |
other places around the web. | |
mid-kid wrote 1 day ago: | |
I'd agree with your message if systemd was just an init system. | |
bryanlarsen wrote 1 day ago: | |
It's not difficult to use some parts of systemd without using | |
others. Is it any different than something like coreutils, another | |
package of linux utilities that are synergistic but usable | |
seperately? Nobody complains about coreutils being bundled. Even | |
the rewrite in rust crowd bundle them. | |
j16sdiz wrote 19 hours 11 min ago: | |
No. | |
The real nightmare is systemd integration with dbus. | |
jacoblambda wrote 1 day ago: | |
It really is not. This "sudo replacement" (which under the hood | |
is systemd-run) will apparently require quite a bit of the | |
systemd stack to operate. That is not something you have access | |
to in many lightweight container distros or on other non-systemd | |
distros. | |
And coreutils is expected because most people use GNU/Linux. | |
Coreutils is that GNU userland part. And either way, the majority | |
of coreutils are GNU implementations of standard unix components. | |
You can use most software that depends on coreutils on other *nix | |
platforms like BSD for this reason. | |
bryanlarsen wrote 1 day ago: | |
I doubt you'll need to run systemd as pid 1 to use this. | |
navaati wrote 1 day ago: | |
Oh you do: this work completely differently from sudo, there | |
is no suid binary involved, instead it does IPC to the | |
systemd pid 1 and asks it to spawn you process, attached to | |
your current terminal. So if you don't have systeme as pid 1, | |
it'll have noone to talk to. | |
Whether you like that or not is for you to decide. | |
bryanlarsen wrote 1 day ago: | |
IPC will likely be over d-bus. The new process will fork | |
off a systemd which is almost always pid 1, but it might | |
not have to be. | |
dijit wrote 1 day ago: | |
are there any non-systemd DBus options anymore? I had a | |
hard time a year ago setting up Gentoo because there were | |
no maintained options at that time. | |
jacoblambda wrote 1 day ago: | |
There are. Gentoo has actually always used the | |
FreeDesktop reference implementation instead of sd-bus | |
(the systemd implementation). | |
FreeDesktop also maintains a list of implementations | |
(also including bindings so you have to read to find | |
which ones are full impls vs libdbus bindings). | |
[1]: https://www.freedesktop.org/wiki/Software/DBus... | |
hxelk1 wrote 1 day ago: | |
> you can actually declare startup dependencies and other useful | |
relationships | |
In theory, yes. In practice, I had a lot of trouble ordering things | |
correctly in non-trivial cases. | |
> it's quite annoying that the armchair linux experts complain about | |
how "lol systemd is so stupid for reinventing the wheel, give me my | |
shell scripts back" | |
I can only speak for myself, but I don't want the abysmal sysvinit | |
scripts back. I just want a simple process supervision suite which is | |
true to the UNIX way of doing things. The sysvinit/systemd dichotomy | |
is false. | |
Runit and s6 are both very real alternatives to systemd. They lack a | |
ton of features, but they are a way to reliably run services. They do | |
use shell scripts, but not for the reasons sysvinit did. They are | |
extremely simple and have a very small attack surface as a result. | |
Runit itself is a spiritual descendant of daemontools which predate | |
systemd by great many years. | |
The problem with systemd is that it's a mediocre solution to many | |
problems. UNIX deserved better. | |
[Edit: whitespace] | |
jauntywundrkind wrote 1 day ago: | |
The other pieces are also pretty excellent. Ifup gave me no joy & | |
was very limited. Systemd-networkd is a wonderful option with vast | |
& great capabilities, that meshes well with the init process & it's | |
style. Systemd-timesyncd is fine, I dunno, works for me. | |
Systemd-journald is probably the weakest of the batch but mostly | |
because it's not very ambitious; I loath that there's no way to | |
really deal with super-active programs hogging all the logspace, | |
short of configuring a second journald instance for that program, | |
which ain't no joy to setup. Systemd-home is a cool set of features | |
for portability. Systemd-nspawn is a bit ahead of its time & looks | |
a little weird now but was a very novel & powerful thing to have | |
built in to most systems. Systemd-resolved is a pretty good local | |
DNS that handles mdns and much weirder cases easily. Systemd-boot | |
is a really nice easy to work with uefi boot loaders that's worlds | |
easier to deal with than uboot or gasp grub. | |
All of these are taken em or leave em. But they're good | |
expectations to have. I love the bazaar model, but Linux used to | |
have so few common expectations, used to manage various bits so | |
poorly. And now there's a much better base of capabilities, which | |
have universal patterns of management that tend to apply to them | |
(how etc files are laid how, being dbus and maybe varlink | |
accessible). Linux hadn't been growing; when you came to a random | |
systems you expected enormously little and typically got it, and | |
what extras were available were scattered/random and often not | |
particularly high quality or capable software. Systems has extended | |
a much bigger base of competency & capability. That we can plug in | |
a USB drive and systemd-home can create an isolated dynamic user | |
out of that & let that user securely run their environment there is | |
a neat as heck expectation. That our network manager supports | |
setting up such a wide range of bridges and tunnels and taps and | |
tuns is fantastic, is excellent. I don't have words for people | |
turning their noses up at this better world; this is so much more | |
competent & capable a world than where we were, gives us so much we | |
all can now take for granted, and it's been done smartly, more | |
mono-repo than monolithic, such that you can do alternatives. But | |
many of these pieces are utterly without peer. And the consistency | |
of operation you get, the predictability of use, from being under | |
the same umbrella, is an ergonomic wonder that is unmatched. | |
ghostpepper wrote 1 day ago: | |
Is there a good overview of these pieces and what they're | |
responsible for and how they fit together? | |
I had a quick skim of the docs on systemd.io and there are quite | |
a few documents but they don't seem particularly organized and I | |
couldn't see a good architecture overview. | |
mattpallissard wrote 1 day ago: | |
I hate to be this guy but the man pages have it all | |
man -k systemd | |
There's some terminology to learn, but overall it's pretty | |
approachable. | |
Edit; and as far as architecture goes they are all _separate_ | |
programs. It's not a single large "systemd" | |
mid-kid wrote 1 day ago: | |
In a similar vein, systems like openrc use "shell scripts" as well, | |
but can generally be written declaratively[1]. This provides | |
greater flexibility when it comes to creating one-shot services or | |
services that require a little setup before running, as you can | |
just re-define the start() function, rather than requiring one to | |
make a separate shell script for it, or dependency tree, like you'd | |
have to in systemd land. | |
"sysvinit" is an ill-defined concept, anyway, as every distribution | |
had their own scripts and tooling around actual services, and | |
sysvinit was generally only responsible for starting getty and | |
launching the distribution's actual service system. How initscripts | |
were created and how you managed them depended significantly on the | |
distribution. | |
[1] | |
[1]: https://gitweb.gentoo.org/repo/gentoo.git/tree/net-vpn/tai... | |
declarethroway wrote 22 hours 17 min ago: | |
Debian's sysvinit scripts can also be declarative. [1] The full | |
system also cares about dependencies and parallel running. And | |
this is not recent, but the black legend will never die. | |
Bonus: by having the shipped scripts under /etc, tools like | |
etckeeper can show your changes as well as updates, all in one | |
place. | |
[1]: https://github.com/DanielAdolfsson/ndppd/blob/master/ndp... | |
Faaak wrote 1 day ago: | |
Yeah, basically I've found that the people the more vocal against | |
systemd are either not really knowing how it works behind the scenes, | |
and just criticizing for the sake of it (or because other people do | |
so), or criticizing from an ideological point of view (do one thing | |
and do it well). They see systemd as an octopus, not following the | |
unix ideology. Which I don't really agree tbh | |
dijit wrote 1 day ago: | |
I think this is a really old statement. Iâve used systemd since | |
it was made default in Fedora back in 2011 (Lovelock, anyone?) - at | |
what point am I qualified to have an opinion, after having used it | |
personally for 13 years and professionally for 8. | |
systemd is scary for 3 reasons. | |
1. it is inscrutable. Debugging it is nearly impossible, so you had | |
better hope you donât get a buggy release, especially with how | |
hostile the devs can be. | |
2. it is large, and growing. Lots of things it claims are optional | |
are in reality: not really. This is fine until uou get something | |
that really doesnt work well (systemd-resolved is consistently the | |
largest reason I have connectivity issues, wether it be because it | |
interferes with docker inter-container networking or because it | |
needs to time-out when trying DNSSec to continue- or if it fights | |
with my vpn provider for power over my resolvers etc). Due to my | |
distro being very tied to it: I gotta keep using it and working | |
around it. | |
3. The interface is irreplaceable. Why are their 13 init systems? | |
Because init is a closed scope. To be a sucessful init you need to | |
spawn processes and do it cheaply. Supervising processes after | |
start? Noble, and there were implementations that could do that | |
(CDDL licensed SMF from Solaris for example). However we have | |
already reached the state where it will be literal man-decades of | |
work to replace systemd as we will need to make any replacement bug | |
compatible with systemd itself. Its the ultimate show stopper. | |
The implementation is the reference. Which is a large departure now | |
from what came before. | |
jacoblambda wrote 1 day ago: | |
The issue is that it's not just ideological. "Do one thing and do | |
it well" is important because if you want to port software to | |
another platform, it's a lot easier to port a single dependency | |
component over to make it work than it is to port over the entire | |
framework. | |
This is a serious problem and it makes it way harder to make things | |
cross platform. | |
Xylakant wrote 1 day ago: | |
Systemd was written specifically for Linux, hard depends on a | |
list of features provided by the Linux kernel and leverages them | |
to do its work. Porting it to another kernel is a rewrite. Lack | |
of portability is in this case a design tradeoff. | |
fhars wrote 1 day ago: | |
The argument was that this design of systemd makes it hard to | |
write applications that are portable, so that systemd is | |
effectively a very big net negative to the open source | |
ecosystem, because it causes massive fragmentation. | |
jacoblambda wrote 1 day ago: | |
Sure that is the case for systemd itself but it's not the case | |
for most projects that happen to use things systemd provides. | |
There is very little benefit for most userspace software to tie | |
itself to systemd and by extension linux when otherwise it | |
could be portable to any unix or unix like platform. Especially | |
when an alternative, portable solution already exists and is | |
well established. | |
dcow wrote 1 day ago: | |
I love systemd. | |
andrewstuart wrote 1 day ago: | |
Me too. The best thing about Linux. | |
jbverschoor wrote 1 day ago: | |
It's a re-implementation of Apple's launchd. I've always liked it | |
though | |
freedomben wrote 1 day ago: | |
It is much more than just a re-implementation of launchd. I | |
can't grab a link right now, but Lenart wrote a long blog post | |
about the philosophical decisions behind systemd, and he goes | |
into detail about what he liked from launchd and what he did | |
not like. It is called "rethinking PID 1" | |
bryanlarsen wrote 1 day ago: | |
A much improved version of launchd, yes. | |
KaiserPro wrote 1 day ago: | |
Thats fine, and lord knows we probably need a replacement to sudo. | |
However, sudo needs to be user friendly and fail safe with decent | |
information as to why its failed. Something that service files | |
historically didn't do. | |
But, the way it's supported also needs to change, it almost certainly | |
needs to be decoupled from systemd's release cycle. | |
I hope that we have all learnt from early systemd, and that we all | |
won't take a "lets piss on each other's chips" approach. I'm too old | |
you you lot to start flame warring over stuff you'll never actually | |
fucking use. | |
mynameisnoone wrote 1 day ago: | |
doas exists but isn't universally available but already solves this | |
problem. sudo has too many features and permits excessive | |
configuration, but it also has the convenience of ubiquity. Inventing | |
a third thing tied to systemd is absurd and unnecessary. | |
constantcrying wrote 1 day ago: | |
Why do they have to do this? This is really, really stupid. | |
My issue isn't even that someone tries to replace sudo. That may or may | |
not be a completely fine thing to do, depending on the state of sudo | |
and what improvements can be made. But what makes me really upset is | |
this completely unexplainable need to make everything part of one | |
particular init system. There is absolutely no reason to tie your new | |
sudo replacement to systemd. Absolutely none. | |
This is a completely insane way to develop software, instead of | |
creating a new piece of software in a separate project they will force | |
all their projects simultaneously onto all their users for absolutely | |
no reason. | |
I am very glad to have jumped ship from systemd. It is particularly bad | |
software created by a team of people who engage in very bad practices | |
and a totally unhealthy view of software in general. | |
paulddraper wrote 1 day ago: | |
> There is absolutely no reason to tie your new sudo replacement to | |
systemd | |
It is said right there: the reason is to avoid the awkward SUID | |
issues, and to have a privileged process create the process. | |
immibis wrote 1 day ago: | |
Instead you get awkward state management issues. Will the child | |
really inherit everything it needs from the parent or has systemd | |
forgotten to transmit something? If I chroot and then run0 will | |
that process also run in the chroot? What about systems with older | |
versions of systemd? | |
_flux wrote 17 hours 6 min ago: | |
I imagine these questions are what might make this project | |
non-trivial, but surely achievable. | |
> If I chroot and then run0 will that process also run in the | |
chroot? | |
That's an interesting question and it's not quite clear to me | |
what should be the answer. For example, one legit answer might be | |
that it would not work at all (in which case you would need to | |
use some other tool that fits your needs), or another would be | |
that the policy can decide what to do in that case. | |
But wouldn't you agree that it is better security hygiene to | |
explicitly opt-in to inheriting properties when going to an | |
elevated security level, instead of opting out from them? | |
Dalewyn wrote 1 day ago: | |
>This is a completely insane way to develop software, instead of | |
creating a new piece of software in a separate project | |
I appreciate and respect the KISS sentiment of doing one thing and | |
doing it well, but oftentimes I also think open source programs' lack | |
of integration with each other at a fundamental level is also one of | |
its biggest downsides. | |
Being a Windows wizard unlike most folks around these parts, seeing | |
and using the tight integrations between all the Windows subsystems | |
is frankly marvelous and I wish Linux could have something like that. | |
tuna74 wrote 1 day ago: | |
Linux is "just" an OS kernel. Integrations between user space | |
programs have to be done by other people (like the systemd | |
developers). | |
viraptor wrote 1 day ago: | |
It's not unexplainable. Any init by design is supposed to spawn new | |
processes with the given environment, permissions, capabilities. When | |
you run "your-init-cli start foo", you're starting a new service | |
process. run0 is just one step away from that, because it connects | |
the terminal to that process. | |
It's less "a new thing has been created with systemd" and more "a | |
user interface was exposed for an existing functionality". | |
zokier wrote 1 day ago: | |
Instead of just hating based on assumptions it would be useful to | |
actually familiarize with the thing you are critizising | |
> But what makes me really upset is this completely unexplainable | |
need to make everything part of one particular init system | |
systemd is not init system, its and umbrella project for various core | |
system components, which includes an init system. | |
> There is absolutely no reason to tie your new sudo replacement to | |
systemd | |
well, in this case there is good reason to have it interact with | |
service manager in general | |
> But with one key difference: itâs not in fact SUID. Instead it | |
just asks the service manager to invoke a command or shell under the | |
target userâs UID [...] 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 | |
strictly speaking it's not 100% coupled to systemd specifically, it | |
most likely uses systemds d-bus API, which is part of their "portable | |
and stable" APIs and as such could be implemented by other service | |
managers [1] > This is a completely insane way to develop software, | |
instead of creating a new piece of software in a separate project | |
they will force all their projects simultaneously onto all their | |
users for absolutely no reason | |
The couplings between systemd projects are not that tight, you can | |
pick and choose which parts you want, they explicitly are not | |
"forcing all their projects" to consumers. The minimal systemd build | |
has only init, journald, and udev, which is not exactly sprawling | |
huge. All the rest of the projects are fully optional, and I believe | |
quite many of them can actually work without systemd-init | |
[1]: https://systemd.io/PORTABILITY_AND_STABILITY/ | |
mid-kid wrote 1 day ago: | |
> systemd is not init system, its and umbrella project for various | |
core system components, which includes an init system. | |
The point being made is that it directly depends on the init system | |
part. | |
> well, in this case there is good reason to have it interact with | |
service manager in general | |
I disagree! There's no reason to not have it be its own daemon with | |
its own configuration and looser bindings to the rest of the | |
systemd ecosystem (e.g. through dbus and other protocols). KDE | |
applications do this a lot, where they take advantage of other KDE | |
components if present. This is strictly a philosophy thing and not | |
a requirement for achieving what he proposes. | |
> their "portable and stable" APIs | |
"we're portable if you reimplement our APIs", idk how this is an | |
argument. They consistently make very little effort to be | |
compatible with (or provide fallbacks for) what's already there. | |
Having stable APIs is nice but there's a reason most of the | |
interfaces on that page don't have alternative implementations: | |
They solve questionable problems and provide no tangible benefits | |
over the methods there were before. Yet projects feel compelled to | |
hard-depend on them... | |
> The couplings between systemd projects are not that tight, you | |
can pick and choose which parts you want, they explicitly are not | |
"forcing all their projects" to consumers. | |
In practice they are. The primary reason why everything is shipped | |
as a single project is because that makes it easier to make | |
available in different distros (they just enable everything), | |
allowing it to become the "de facto" standard since it's available | |
everywhere. There's a lot of projects that solve some of the | |
systemd tools' in sometimes better ways, that never see the light | |
of day because they don't have a trojan horse to ride in with. | |
There's a reason why projects like elogind exist, because there's | |
only a very select few systemd tools that work without systemd at | |
all | |
constantcrying wrote 1 day ago: | |
Half the people here tell me that systemd is great because it tries | |
to create an integrated complete system, the other half tells me I | |
can just pick and choose. | |
Obviously one of these groups is lying. | |
kergonath wrote 1 day ago: | |
Replace âsystemdâ with âGNUâ and it might be clearer… | |
âGnomeâ, or âKDEâ). Yes, they are built to work toge… | |
No, they are not monoliths. | |
thiht wrote 1 day ago: | |
Both can be true though, it can create an integrated system where | |
everything systemd-* works together, but where you can replace | |
any systemd-* you donât like with something else | |
constantcrying wrote 1 day ago: | |
The point of an integrated system is that interactions between | |
components enhance the system as a whole. This is obviously | |
incompatible with an easy replacement of components. | |
This is literally just basic systems engineering. I don't even | |
know what you are arguing here. The more tightly integrated a | |
system is the harder it is to replace individual components. | |
wmf wrote 1 day ago: | |
You can replace most systemd components but in that case you | |
have fewer features and probably more code overall. If you | |
run the whole systemd bundle you get more features. | |
thiht wrote 1 day ago: | |
> This is literally just basic systems engineering | |
Well⦠yes it is. Public interfaces and contracts, anyone? | |
Decoupling? | |
constantcrying wrote 1 day ago: | |
The more tightly integrated a system is, the more involved | |
the contracts between the components become. I seriously | |
didn't believe that a single person here would disagree | |
with that. | |
A component that depends on one simple interface is far | |
easier to replace than one which depends on twenty complex | |
ones. This seems like the most basic stuff. | |
growse wrote 1 day ago: | |
You can have a well-integrated system without having tight | |
coupling between components. Interfaces are a thing, and a | |
high level of integration just means having a good collection | |
of interfaces between well-defined conceptual components with | |
well-defined capabilities. The actual software that | |
implements those components is entirely separate. | |
constantcrying wrote 1 day ago: | |
I don't know what you are arguing. Replacing a component in | |
a tightly integrated system means that the component has to | |
be compatible to that tightly integrated system, meaning | |
lots of assumptions and replication of functionality. | |
This means components have to tightly conform to the | |
components they are replacing, which obviously decrease | |
modularity as these components are harder to maintain for | |
available system configurations. | |
This isn't about whether someone can rewrite a part of | |
systemd, but whether you can freely mix and match, which | |
tight integration works against. Obviously | |
dale_glass wrote 1 day ago: | |
> But what makes me really upset is this completely unexplainable | |
need to make everything part of one particular init system. There is | |
absolutely no reason to tie your new sudo replacement to systemd. | |
Absolutely none. | |
You should look at it differently, and then it'll make perfect sense. | |
systemd has long stopped being just an init system. It's a system | |
tooling suite. When thinking about systemd don't think "PID 1", think | |
"Linux New System Software Suite". It's a big umbrella project in the | |
style of Gnome and KDE. | |
For example, systemd-boot is a perfectly normal bootloader that's | |
just been systemd-themed. It has a "ctl" tool, has the same | |
command-line aesthetics as other systemd-group tooling, and so on. | |
It's not in any way dependent or even interested in the init system. | |
constantcrying wrote 1 day ago: | |
>systemd has long stopped being just an init system. | |
I think that this has always been the core criticism of anyone who | |
objects to them. Besides systemd, the init system, just being very | |
poorly thought out. | |
dale_glass wrote 1 day ago: | |
What's poorly thought out about the init system? It's not perfect | |
for sure, but on the whole I don't have any issues with it. | |
constantcrying wrote 1 day ago: | |
How much time have you spent writing and debugging systemd init | |
files? | |
dale_glass wrote 1 day ago: | |
I've written a fair amount. Nothing much to debug in most of | |
them. | |
constantcrying wrote 1 day ago: | |
Riddle me this: can I create new mount files inside a | |
systemd unit and have them activated to mount the locations | |
specified? Do I need a daemon reload, for this? | |
Spivak wrote 13 hours 3 min ago: | |
Yes you need a daemon reload to discover the new unit | |
files. Is there in issue with doing this? A reload means | |
reread its config, it's not a reexec. | |
dale_glass wrote 1 day ago: | |
That sounds like a job for systemd.generator. | |
I don't think having an unit that generates units at | |
runtime is an officially supported use case, since | |
generators exist. | |
constantcrying wrote 1 day ago: | |
This doesn't answer the question. Also generators are | |
started very early, before other units have been | |
started, so if your system is already running and now | |
you want to generate those units, depending on the | |
state of the other units, they don't really help. | |
>I don't think having an unit that generates units at | |
runtime is an officially supported use case | |
Are you sure? Can you tell me how I would find out? | |
dale_glass wrote 1 day ago: | |
> This doesn't answer the question. Also generators | |
are started very early, before other units have been | |
started, so if your system is already running and now | |
you want to generate those units, depending on the | |
state of the other units, they don't really help. | |
That's the point. Any situation in which you have a | |
system modify itself at runtime is a recipe for a | |
headache. So you do your auto-generation first, then | |
work from a stable state. | |
> Are you sure? Can you tell me how I would find out? | |
Aside from that this kind of recursion seems like a | |
great way to get weird problems, and that generators | |
exist for this exact thing, the whole design of | |
systemd discourages this kind of trickery. Units are | |
just supposed to start a command and little else. | |
Maybe somebody made an official pronouncement on this | |
somewhere, but my personal take on this kind of thing | |
is that it's a bad idea, anywhere, not just systemd. | |
rascul wrote 1 day ago: | |
> Units are just supposed to start a command and | |
little else. | |
Units are not just for services. | |
From systemd.unit(5) man page: | |
> A unit file is a plain text ini-style file that | |
encodes information about a service, a socket, a | |
device, a mount point, an automount point, a swap | |
file or partition, a start-up target, a watched | |
file system path, a timer controlled and supervised | |
by systemd(1), a resource management slice or a | |
group of externally created processes. | |
constantcrying wrote 1 day ago: | |
>So you do your auto-generation first, then work | |
from a stable state. | |
You can't do auto generation if that generation | |
depends on the output of some units. Generators can | |
not solve that problem. | |
>Units are just supposed to start a command and | |
little else. | |
What a bizarre thing to say. No, that is not just | |
what units are for. I think you are severely | |
misinformed about what systemd is. Units are | |
supposed to take care of ordering accept IPC, | |
define how to handle failures and manage devices. | |
That comment alone makes me believe that you just | |
do not know what you are talking about at all. It | |
completely misses why systemd is designed the way | |
it is and what it tries to accomplish. | |
dale_glass wrote 1 day ago: | |
> You can't do auto generation if that generation | |
depends on the output of some units. Generators | |
can not solve that problem. | |
True | |
> What a bizarre thing to say. No, that is not | |
just what units are for. I think you are severely | |
misinformed about what systemd is. Units are | |
supposed to take care of ordering accept IPC, | |
define how to handle failures and manage devices. | |
I mean that part of the point of systemd is that | |
units mostly work out to | |
ExecStart=/usr/bin/binary, and an unit isn't | |
supposed to contain the arbitrary jank one can | |
put into a SysV script. | |
IPC and the like is an explicit systemd feature, | |
not something you improvise behind the scenes and | |
then expect to work anyway. | |
Jonnax wrote 1 day ago: | |
Is that really how they develop software? | |
Because I'm pretty sure that most of the components are optional. | |
You did not even discuss the reasoning given for not using sudo to | |
instead hop on your soapbox to say it's bad software with bad | |
practices and that they are stupid. | |
It's annoying how in the the more surface level Linux communities | |
there's 0 value in discussing systemd. | |
"1 million lines of code for PID0!" | |
The new thing is blaming systemd for that recent exploit even though | |
distros were patching in the bug themselves. | |
People analysing the exploit determined that a new version of systemd | |
was going to prevent the exploit vector so the exploit seemed to have | |
been rushed out. | |
Isn't this just textbook FUD? | |
What I've noticed is over the years is systemd would have identified | |
a gap in functionality. | |
Like systemd-homed having a solution for automatically encrypting | |
home directory when the machine is suspended. | |
Is that a functionality that OSX has had for years? Yes. | |
But anti-systemd people will dislike it automatically. | |
constantcrying wrote 1 day ago: | |
Why are you bringing up random arguments I didn't even make? | |
No, I am a dedicated systemd hater ever since I spend over a month | |
full time writing and debugging systemd services for work. Systemd | |
(the init system) is just all around badly designed and executed, I | |
have very little confidence in the developers and their technical | |
abilities and their tendencies to expand into completely unrelated | |
areas for seemingly no reason makes me quite concerned. | |
I wouldn't blame the xz exploit on them, it is very hard to call it | |
their fault in any way. But I do think it is a symptom of a system | |
which has grown far too thin and wide. | |
Jonnax wrote 1 day ago: | |
Because your post is the repeating cliches that are under every | |
discussion about systemd. | |
You're essentially saying that the month you spent is enough for | |
you to call it bad and the creators incompetent. | |
What qualifies you to make a determination like that? | |
There is never any actual technical reasons it's always about | |
vague things like not adhering to UNIX philosophy, lines of code | |
or it being badly designed (without any real architectural | |
criticism) | |
This is an article about why they believe sudo isn't a good | |
system. Where's your criticism of that from a technical / | |
security perspective? | |
It's been about 10 years since systemd was adopted by | |
Debian/Ubuntu/Redhat/Fedora etc. | |
Millions of deployments over the years. The companies that build | |
and are paid to support for years with SLAs the operating systems | |
are using it without issue. | |
constantcrying wrote 1 day ago: | |
>There is never any actual technical reasons it's always about | |
vague things like not adhering to UNIX philosophy, lines of | |
code or it being badly designed (without any real architectural | |
criticism) | |
I did not mention the first two, so please do not pretend I | |
argued that. For bad design look at transactions. That is | |
really dumb and makes the system near incomprehensible. The | |
documentation is bad, dbus is literally so bad they tell you | |
not to use it without a wrapper. The terminology is very | |
questionable and makes it hard to explain what a unit actually | |
does. | |
But I don't even see that as the worst part. The worst part is | |
that they fundamentally can't do basic software engineering, in | |
the sense that they do not have a defined project scope. | |
Everything is potentially a systemd issue and not once does | |
anyone take a step back and say "maybe systemd" isn't the right | |
place to fix that problem. | |
>This is an article about why they believe sudo isn't a good | |
system. Where's your criticism of that from a technical / | |
security perspective? | |
If you don't read my posts please do not respond to me. Look at | |
the first post I made and carefully read it. | |
growse wrote 1 day ago: | |
> If you don't read my posts please do not respond to me. | |
Look at the first post I made and carefully read it. | |
I read your OP. It does not contain a technical / security | |
criticism of run0. It's an angry, hand-wavey, vague rant | |
against a project that took a design decision you apparently | |
disagree with, but lacking any actual analytical evaluation | |
of the thing up for discussion. | |
This sort of top-level post shows up on every single article | |
that mentions "systemd", so you'll maybe understand why | |
people tend to be dismissive. | |
constantcrying wrote 1 day ago: | |
>I read your OP. It does not contain a technical / security | |
criticism of run0. | |
Yes, I literally say there is nothing wrong with the idea, | |
so you going ahead and demanding I criticize the idea, is | |
just absurd. | |
Really, this is completely bizarre. I even say that the | |
thinking behind replacing sudo is fine, yet you are here | |
complaining that I don't deliver technical arguments | |
against something which I even told you might be completely | |
valid to do from a technical perspective. Baffling. | |
growse wrote 1 day ago: | |
Let me get this right: you see an article on a new thing, | |
which you have no problem with, but have an angry rant in | |
the comments section anyway? And now you're baffled by | |
people's reaction to that? | |
I'm not sure there's much point engaging further, I hope | |
you have a good rest of the day. | |
constantcrying wrote 1 day ago: | |
No, I think the systemd project shouldn't exist. I have | |
no problem with someone writing a sudo replacement. | |
Do you understand the difference? | |
SAI_Peregrinus wrote 1 day ago: | |
Do you also think the GNU project shouldn't exist? If | |
not, what's the difference? | |
yjftsjthsd-h wrote 1 day ago: | |
I can use GNU bash on NetBSD with no other GNU | |
software installed. I can install GNU coreutils on | |
Alpine Linux (complete with musl libc instead of | |
glibc). In fact, it's possible to just install a | |
single part of GNU coreutils but not the rest - ex. | |
Alpine packages just sha512sum as [1] (not sure | |
why). I don't think I've seen it done, but you | |
could build a Linux distro that used glibc and gcc | |
but no other GNU software (busybox coreutils and | |
ksh shell, say). GNU has their own kernel, but is | |
predominantly used on other OSs. They want to build | |
all the pieces, but you can opt in or out of all of | |
them, and they're all portable. In contrast, if you | |
want to use, say, run0, you must run systemd as PID | |
1, you must use journald, and the whole stack only | |
runs on Linux. So yeah, that is actually different. | |
[1]: https://pkgs.alpinelinux.org/contents?bran... | |
growse wrote 1 day ago: | |
> and they're all portable... | |
I think that portability is a deliberate | |
anti-goal of systemd. | |
> In contrast, if you want to use, say, run0, you | |
must run systemd as PID 1, | |
No, you must run something on pid 1 that | |
implements the spec, similar to how musl can be | |
used instead of glibc - they both implement the | |
same spec. | |
Run0 expects pid 1 to behave a certain way, much | |
like my web browser expects web servers to behave | |
a certain way. | |
yjftsjthsd-h wrote 8 hours 54 min ago: | |
> I think that portability is a deliberate | |
anti-goal of systemd. | |
Yes, and that is one of the things I dislike | |
about it. (In fairness, the list of things I | |
like about it and the list of things I dislike | |
about it are both fairly long.) | |
> No, you must run something on pid 1 that | |
implements the spec, similar to how musl can be | |
used instead of glibc - they both implement the | |
same spec. | |
> Run0 expects pid 1 to behave a certain way, | |
much like my web browser expects web servers to | |
behave a certain way. | |
If there's only one implementation, then it's | |
not portable. If a webapp uses a web API that | |
only Chrome implements, it's not portable | |
regardless of whether Google published a spec | |
for their non-standard behavior. There are | |
dozens of web servers and web clients that all | |
speak HTTP, there is one systemd. | |
growse wrote 8 hours 22 min ago: | |
Once upon a time, there was only one web | |
browser too. | |
hxelk1 wrote 1 day ago: | |
I've spent a lot of time studying systemd alternatives. I believe the | |
overall best design is Skarnet's s6, and that too includes a | |
sudo-like program: [1] I was very surprised when I learned about it, | |
but it does make sense (for s6 at least). | |
> There is absolutely no reason to tie your new sudo replacement to | |
systemd. Absolutely none. | |
With s6, the idea is to replace a SUID binary with an IPC mechanism. | |
That does make sense, since (parts of) the init system need to be | |
running as root. | |
> I am very glad to have jumped ship from systemd. | |
All that aside, so am I. | |
[1]: https://skarnet.org/software/s6/s6-sudo.html | |
deng wrote 1 day ago: | |
> With s6, the idea is to replace a SUID binary with an IPC | |
mechanism. That does make sense, since (parts of) the init system | |
need to be running as root. | |
Same idea with systemd-run. | |
lugu wrote 1 day ago: | |
The article explains how this sudo replacement ties to systemd: | |
> But with one key difference: itâs not in fact SUID. Instead it | |
just asks the service manager to invoke a command or shell under the | |
target userâs UID. | |
I understand your frustration, but systemd isn't the first attempt to | |
build an integrated system. It just happens to run on Linux. It isn't | |
insane to develop software this way, from that perspective. | |
deng wrote 1 day ago: | |
> But what makes me really upset is this completely unexplainable | |
need to make everything part of one particular init system. | |
It is not unexplainable at all. In fact, the article explains it very | |
well. | |
sudo allows you to execute code as another user. If you think about | |
it, you could also replace sudo with ssh to localhost - just set a | |
root password and allow root logins. Now, security-wise, this would | |
obviously be a bad idea. Our current solution is to give the sudo | |
binary itself administrative privileges, which is a slightly less bad | |
idea, but still pretty bad. | |
Systemd already handles logins, so it is quite obvious that it could | |
also handle this problem very well, and in fact, it already does: | |
there is a tool systemd-run which you can already use. It will create | |
a completely new process and will handle communication to it, just | |
like ssh, but without the above downsides. | |
constantcrying wrote 1 day ago: | |
>Systemd already handles logins | |
Exactly that was my objection. | |
deng wrote 1 day ago: | |
And I disagree with that. The 'sudo problem' is a good example | |
why it makes sense to handle init and login by the same system | |
(note I'm not meaning "same binary" here, in fact, they are | |
separate binaries in systemd). The SUID approach for sudo has | |
been a problem for decades, and it needs to go. I don't really | |
care if it's done by systemd, or if we agree on another system | |
like S6 that was mentioned in another thread - in the end, they | |
work very similarly be replacing the old sudo with an IPC | |
approach. | |
cryptonector wrote 1 day ago: | |
I agree with u/constantcrying. This should not be part of | |
systemd. It should be a separate service [started by systemd]. | |
Reasons: | |
- systemd is a large beast -- no need to make it larger with | |
unrelated things | |
- the Unix philosophy seems to be applicable here | |
- the result should be portable to non-systemd systems | |
deng wrote 17 hours 23 min ago: | |
> systemd is a large beast -- no need to make it larger with | |
unrelated things | |
I think I sufficiently explained why it is very much related. | |
> the Unix philosophy seems to be applicable here | |
Systemd very much follows the unix philosophy. It is not one | |
big binary, but actually consists of dozens and dozens of | |
tools communicating with each other through protocols. | |
> the result should be portable to non-systemd systems | |
Portable on what basis? POSIX? | |
cryptonector wrote 11 hours 7 min ago: | |
> I think I sufficiently explained why it is very much | |
related. | |
This: | |
| Systemd already handles logins | |
? | |
But I don't see why a bring-up/shutdown system should | |
handle logins. | |
> Systemd very much follows the unix philosophy. It is not | |
one big binary, but actually consists of dozens and dozens | |
of tools communicating with each other through protocols. | |
That is fine. As long as this service (sudo replacement) | |
is a standalone, separate daemon started by a systemd unit, | |
I'm happy. If it's a core part of systemd itself then I'm | |
not happy. | |
> Portable on what basis? POSIX? | |
Or Linux / glibc / musl, sure, why not. Some people (no, | |
not me) want to run Linux w/o systemd. The point is that a | |
sudo replacement service should be fairly portable to the | |
universe of UNIX/Unix/BSD/Linux. | |
Spivak wrote 13 hours 8 min ago: | |
People who just have an axe to grind with systemd really | |
don't like when you point out that it's incredibly modular | |
and follows the unix philosophy. | |
I think what people mean to say but don't have the words | |
for is that systemd is an East coast school of thought | |
project and folks prefer "worse is better" style tools. | |
cryptonector wrote 11 hours 11 min ago: | |
I like the idea behind systemd. I don't have an axe to | |
grind. I don't want SysV init or whatever you might | |
think. | |
Faaak wrote 1 day ago: | |
I find this quite clever. Yeah yeah, "systemd is bad, it's a | |
monopoly, yadda yadda". | |
Well, there's also a reason they are doing it, and many aspects of it | |
(seatd, timesyncd, resolved, run), and more neat than cobbling | |
together bash scripts. I like it | |
Starlevel004 wrote 1 day ago: | |
> But what makes me really upset is this completely unexplainable | |
need to make everything part of one particular init system. There is | |
absolutely no reason to tie your new sudo replacement to systemd. | |
Absolutely none. | |
The systemd developers are tying it to systemd because they are | |
systemd developers. If somebody else made something like this, it | |
wouldn't be tied to systemd. But somebody else hasn't made something | |
like this. | |
Sudo isn't going to just go away (unfortunately). You can keep using | |
your CVE-ridden setuid binary as much as you want. | |
crashmat wrote 1 day ago: | |
noting I have been recommended doas as a more lightweight version | |
of sudo so other people are trying to do this kind of thing | |
fanf2 wrote 1 day ago: | |
userv has been around for decades | |
[1]: https://www.chiark.greenend.org.uk/~ian/userv/ | |
constantcrying wrote 1 day ago: | |
>The systemd developers are tying it to systemd because they are | |
systemd developers. | |
What? Literally every single other group of software developers has | |
managed to create two projects. Even Microsoft can do it. | |
SAI_Peregrinus wrote 1 day ago: | |
GNU didn't. Why should Systemd? | |
gkbrk wrote 1 day ago: | |
You can use almost any GNU project without depending on all the | |
other GNU projects. | |
SAI_Peregrinus wrote 1 day ago: | |
This is different from Systemd how? You can't use any GNU | |
project without depending on GNU libc (except glibc itself, | |
trivially). | |
enriquto wrote 19 hours 34 min ago: | |
That is not true. I use gnu tools compiled with musl libc. | |
dcow wrote 1 day ago: | |
Why is this stupid? Itâs just an option for how to configure a | |
system that uses systemd to allow commands to be run in a privileged | |
execution context without a suid binary. Whatâs wrong with having | |
options? | |
Why donât you propose a better solution? How would your non-systemd | |
solution actually work? | |
dmm wrote 1 day ago: | |
> they will force all their projects simultaneously onto all their | |
users for absolutely no reason. | |
That's just not true. Just because a system uses systemd the init | |
system doesn't mean the it is forced to use the other components. | |
blueflow wrote 1 day ago: | |
The reverse is true: Trying to use a component like udev or logind | |
or in the future, run0, will require the use of systemd. Either you | |
use full systemd or you can't get any of the fancy stuff. | |
Gentoo folks have eudev or seatd but thats an uphill battle. | |
timw4mail wrote 1 day ago: | |
You can't take OpenRC away from me! | |
constantcrying wrote 1 day ago: | |
The single beat reason for doing this is to get a coherent complete | |
system. This is what every other person here says. | |
You can not try to create a large coherent system and then tell | |
people they shouldn't use that particular part. That is totally | |
disingenuous. Systemd is DESIGNED to be an all or nothing deal. | |
growse wrote 1 day ago: | |
> Systemd is DESIGNED to be an all or nothing deal. | |
^[Citation needed] | |
constantcrying wrote 1 day ago: | |
Again and again people in this thread have told me that the | |
great thing about systems is that it delivers integrated tools. | |
kergonath wrote 1 day ago: | |
A lot of people also point out that âintegratedâ â | |
âmandatoryâ and that it is not, in fact, an all or | |
nothing deal. | |
growse wrote 1 day ago: | |
And people are also telling you that tight integration is not | |
a mandate. Having a bunch of stuff designed to work together | |
does not mean that they're tightly coupled and can only work | |
with their specific implementations. | |
We've all got confirmation bias, the trick is to be aware of | |
it. | |
constantcrying wrote 1 day ago: | |
This is such a bizarre statement. Of course any system with | |
tight integration demands more precise specifications. | |
Literally systems engineer 101. | |
This is such an absurd hill to die on. | |
logicprog wrote 1 day ago: | |
You aren't making any sense. All of the components of | |
system D are separate programs, and yes they are | |
maintained by the same general project and designed to | |
integrate well with each other, but just because | |
components are designed to integrate well with other | |
components from the same project if they are present, | |
that doesn't remotely mean that all of the components are | |
required. And I mean, the proof is in the pudding, there | |
are plenty of distros that do not use all of the | |
components of systemd. Also, doesn't Linux have a long | |
history of creating integrated suites of programs | |
designed to integrate well with each other and used | |
together? Like GNU? | |
mise_en_place wrote 1 day ago: | |
sudo and su made sense when it was a multiuser time sharing system. You | |
needed clear boundaries between each users of the system, and | |
permission bits. | |
If Iâm running on my workstation or desktop just let me run the damn | |
thing. I donât need an unprivileged user. On TempleOS you can modify | |
the running system in ways you canât on Linux. | |
foul wrote 1 day ago: | |
Plan9 propaganda in the wild | |
rurban wrote 1 day ago: | |
For one, a good effort by Lennart. | |
Iridescent_ wrote 1 day ago: | |
Wasn't the recent liblzma attack already exploiting the fact that | |
systemd has its hands in pretty much everything? Wouldn't this expand | |
further the attack surface of systemd and the systems that connect with | |
it? | |
SixDouble5321 wrote 1 day ago: | |
I think this is bang on. Let's give it more surface area :/ | |
exe34 wrote 1 day ago: | |
I'm surprised he hasn't started writing his own kernel by now. | |
jbverschoor wrote 1 day ago: | |
systemd operates the system :-) | |
viraptor wrote 1 day ago: | |
That's not a great summary of lzma. It was systems adding custom | |
patch to ssh which used a systemd-related library which it didn't | |
really need in the first place. It's a stack of issues that don't | |
have much to do with systemd itself really. | |
But re. expanding the attack surface - unlikely. Systemd's primary | |
purpose is to start processes with the right environment / | |
permissions. systemd-run/run0 basically give you the tool to invoke | |
that functionality with a terminal attached to it. That's smaller | |
scope of extra code than sudo/doas deal with. | |
metta2uall wrote 22 hours 7 min ago: | |
Isn't it a fault of systemd that libsystemd had a dependency on | |
libxz? (because it implements too many things). It should have been | |
possible to add the notification functionality using a tiny | |
libsystemd-notify. | |
viraptor wrote 4 hours 44 min ago: | |
It's not a fault. They needed xz for some functionality and | |
didn't want to split that library into multiple pieces. That's | |
just a choice. | |
But either way, you could always do notification in a few lines | |
yourself (probably as many as you needed to link that library in | |
the first place). I've done multiple 3-line "implementations" in | |
Python and Ruby in the past and never linked it for example. | |
StimDeck wrote 1 day ago: | |
Just a reminder that there are plenty of systemd-less distros | |
available. Also a reminder that those distros would have been safe from | |
the nearly-solar-winds-level backdooring of Linux distros from XZ | |
utils. | |
ranger207 wrote 1 day ago: | |
Also remember that systemd-using distros like, say, Arch were also | |
safe from the nearly-solar-winds-level backdooring because the | |
backdoor targeted specific distros widely used as servers. Obviously | |
the solution to security from backdoors is only using distros that | |
aren't popular for servers | |
nialv7 wrote 1 day ago: | |
Can you even hear what you are saying? Don't you find it ridiculous | |
to blame the XZ backdoor on systemd, instead of the actual hacker? | |
Even if systemd did not exist, the hacker would have just picked | |
something else to infiltrate. | |
pessimizer wrote 1 day ago: | |
> Don't you find it ridiculous to blame the XZ backdoor on systemd, | |
instead of the actual hacker? | |
This is a great argument against all computer security. If you | |
believe in securing your computer, you're supporting hackers. | |
Because if you ever believe that a lock has failed, you're saying | |
the thief is innocent; that's how logic works. | |
nialv7 wrote 5 hours 39 min ago: | |
Well, you conveniently ignored half of my point. Even without ssh | |
depending on systemd (dependency introduced by distro | |
maintainers, not systemd, mind you), a backdoor in xz can still | |
exploit your system in a myriad of ways. | |
And secondly, I would say even if nobody is going to blame me, I | |
would still secure my systems. Why? To protect my data of course. | |
bitwize wrote 1 day ago: | |
Of course, the actual hacker was to blame, but systemd was | |
implicated. The fact that the attacker was willing to settle for | |
compromising just Debian and Red Hat systems indicated that they | |
perceived the path from xz to libsystemd was the easiest way to | |
effect the backdoor and that doing it any other way would have been | |
too much work for marginally little gain (Red Hat and Debian | |
systems being so common). | |
Jonnax wrote 1 day ago: | |
That backdoor was never pushed out of the testing branches for | |
distros. | |
Arnavion wrote 1 day ago: | |
It was in OpenSUSE Tumbleweed for a few days actually (RPM-based + | |
rolling release + did the sshd patch). I was affected by it and it | |
was fun watching the reliable ~100ms difference in `time | |
/usr/sbin/sshd -h` with and without `TERM=foo` | |
wpm wrote 1 day ago: | |
Oh well I guess it didn't matter then. | |
StimDeck wrote 1 day ago: | |
Not sure of the relevance of this comment, can you elaborate? Were | |
you the one that caught it? | |
Our balls were inches from the bandsaw. Systemd made it possible | |
to compromise SSH through an unrelated, single-maintainer lib that | |
wasnât even a dependency. | |
Edit: never mind, I see you are a systemd crusader. | |
rahen wrote 1 day ago: | |
I thought doas had solved this already. | |
NewJazz wrote 1 day ago: | |
Nope, but an instance of sshd only running on localhost could do the | |
trick... | |
progval wrote 1 day ago: | |
doas uses SUID | |
bandrami wrote 1 day ago: | |
It either has to be SUID or it has be a daemon running as root (or | |
with enough caps to make the difference not matter). Adding a | |
needlessly verbose configuration ecosystem doesn't change that. I | |
imagine there's going to be some cool stuff this can do with homed | |
and userctl, but it's not like the fundamental problem of "this | |
program can grant root privileges" can ever go away. | |
dale_glass wrote 1 day ago: | |
The problem is not "this program can grant root privileges", it's | |
that the setuid bit sucks. | |
Linux processes inherit a lot of state from the parent which | |
means it's absolute hell to make a secure setuid binary. And at | |
any time the Linux kernel can add a new feature which will be | |
inherited by a child process, but that the process can't defend | |
against because it wasn't even a thing when the code was written. | |
Running a binary at all also goes through a complex set of | |
initialization steps a lot of programmers barely know exist, let | |
alone are able to understand fully. | |
bandrami wrote 1 day ago: | |
Sure, but your choices are running an on-demand binary suid | |
root, or running a persistent daemon as root. | |
Both have problems, but if you're going to switch users to root | |
you have to do one of them. | |
dale_glass wrote 1 day ago: | |
The tool doesn't try to do away with root, it tries to do | |
await with the setuid bit. Meaning, "running a persistent | |
daemon as root" is the intentional solution, and presented as | |
the significantly better option for good security. | |
kristjank wrote 1 day ago: | |
I am looking forward to the day systemd will implement everything a | |
typical Linux system needs. No more systems greater than the sum of | |
their parts, just a Half-Life 2-style Combine of Microsoft sponsored | |
Poetteringware, running a monolythic system on top of a monolythic | |
kernel, until systemd rewrites the Linux kernel as well. The future is | |
bright! \s | |
Seriously though, this seems to be a decent replacement for sudo if it | |
works as seamlessly as it's described in the article. I still prefer | |
the doas line of approach that simplifies the tool as much as possible, | |
but I see the value of having such an important tool integrated into | |
the existing system tooling, especially if it already includes | |
everything but the kitchen sink. | |
andrewstuart wrote 1 day ago: | |
âSystemdâ and âexpandâ used in the same sentenceâ¦.. a… | |
systemd haters will be triggered like itâs the national rifle | |
association shooting carnival. | |
In many ways systemd has actually become the operating system. Itâs | |
so pervasive that it certainly is more deserving of naming rights than | |
gnu. âSystemd/Linuxâ makes more sense than âgnu/Linuxâ | |
timetraveller26 wrote 1 day ago: | |
"Systemd wants to expand to include a replacement of the Linux | |
kernel" headline coming soon | |
Spivak wrote 12 hours 55 min ago: | |
People have been memeing this for a long time but if you know | |
anything about the project you would know that one of systemd's | |
explicit goals is to use the full capabilities of the Linux kernel | |
to hell if it's not portable to other kernels. | |
blackhaz wrote 1 day ago: | |
Mark my words, you won't be able to see the kernel anywhere in there | |
soon! | |
creshal wrote 1 day ago: | |
But they already ship pkexec together with systemd anyway via polkit, | |
why are they again reinventing a wheel they already reinvented? | |
Unit files are a neat concept I don't want to miss again, but | |
everything else done by Lennart seems to be an inceasingly stupid | |
mistake born from hubris. | |
NewJazz wrote 1 day ago: | |
Not all distros ship pkexec with polkit. Polkit runs fine without | |
pkexec present. This is kind of a non-suid alternative to pkexec. | |
It's really more similar to a local-only ssh though. | |
deng wrote 1 day ago: | |
Because pkexec has the same problems as sudo: it's a SUID binary. As | |
Lennart says, the goal is to eventually get rid of SUID binaries | |
altogether, as they are an inherent security risk. Replacing sudo | |
with pkexec would not change much. In fact, pkexec has had its fair | |
share of local root exploits over the past few years. | |
roenxi wrote 1 day ago: | |
AFAIK privileges are an area that has an easy problem statement | |
("execute this command with that capability") and is fiendishly | |
difficult to execute in practice. `sudo` alone has weird bits to set | |
in the filesystem, magic users and all sorts of unhelpful | |
implications - and it doesn't even lead to any particular security | |
for single-user systems. Same-user code is a scary enough place to be | |
running untrusted code. | |
Those sort of problems sound like the sort that get a lot of attempts | |
which run into the complexity wall and halt. I think Amazon has one | |
of the best implementations of a privilege system I've used and it is | |
horrible. | |
adontz wrote 1 day ago: | |
here's a new tool in systemd, called "run0". Or actually, it's not a | |
new tool, it's actually the long existing tool "systemd-run", but when | |
invoked under the "run0" name (via a symlink) it behaves a lot like a | |
sudo clone. | |
pmlnr wrote 1 day ago: | |
> The developer talks about the weaknesses of sudo, and how it has a | |
large possible attack surface | |
Poettering's hypocrisy is painful. | |
mort96 wrote 1 day ago: | |
Is it? Does systemd's sudo replacement also have a lot of complex | |
code running as root in a suid binary? | |
Because that's what he's complaining about | |
pmlnr wrote 1 day ago: | |
The complaint might be valid. The solution, to shoehorn yet another | |
functionality on systemd will in no way reduce complexity or attack | |
vectors, merely shift them, again, like with all systemd solutions. | |
mort96 wrote 15 hours 47 min ago: | |
What difference does it make if it's part of the systemd project | |
or not? Do things suddenly become a more problematic attack | |
vector when they're organizationally part of the systemd project | |
instead of the sudo project? | |
kreetx wrote 1 day ago: | |
The systemd attack vector is already there, and now the SUID | |
attack vector is removed - sounds like reduction in attack | |
vectors, no? | |
mid-kid wrote 1 day ago: | |
systemd has a lot of complex code running as root (that can be | |
reached without privileges more often than not) and has had its | |
fair share of CVEs. | |
The hypocrisy is in calling out a different project for being an | |
overengineered tool running with too high privileges. | |
mort96 wrote 1 day ago: | |
It's not just about running as root though, but as being in a | |
SUID binary. | |
jpollock wrote 1 day ago: | |
People blame systemd for making the liblzma problem larger than it | |
should have been. [1] "Liblzma ends up dynamically linked to sshd | |
because of a | |
systemd-related extension added by many Linux packagers that pulls | |
in liblzma as an unrelated dependency." [2] "openssh does not | |
directly use liblzma. However debian and several other | |
distributions patch openssh to support systemd notification, and | |
libsystemd does depend on lzma." | |
[1]: https://marc.info/?l=openbsd-misc&m=171227941117852&w=2 | |
[2]: https://news.ycombinator.com/item?id=39866076 | |
mort96 wrote 1 day ago: | |
What relevance does this have? Poettering's complaint is that | |
sudo is way too big for a SUID binary, sshd is not a SUID binary? | |
And neither Poettering nor the systemd developers patched said, | |
the Debian people did that. Seems weird to blame systemd for | |
that? | |
jpollock wrote 1 day ago: | |
The complaint is that the code architecture of systemd results | |
in security problems for their _customers_. | |
The inclusion of a library to send notifications shouldn't have | |
external dependencies, it shouldn't need them. The library is | |
included in the customer's codebase at execution time, so it is | |
a hole in the customer's security model. This immediately opens | |
a supply chain attack vector (which is what we saw). | |
This is being taken as evidence that they shouldn't have | |
responsibility for truly security sensitive code - the | |
replacement of sudo. | |
Some of this is a long-term dislike for systemd and some | |
representative bias. However, Systemd has missed the | |
opportunity to make their client libraries safer. | |
Personally? I wouldn't have thought to limit the dependencies | |
of my client libraries. It's a growth and project age thing. | |
One moment you're on one side of a line, the next you have to | |
skill up and do things differently. | |
Using systemd as intended shouldn't result in security holes | |
for their customers. | |
mort96 wrote 15 hours 55 min ago: | |
"Systemd is bad because Debian patched OpenSSL to add an | |
unnecessary dependency on a systemd library" is just not a | |
good argument, sorry. Nothing about the "code architecture" | |
of systemd caused the xz issue. | |
And again, Poettering's complaint with sudo is specifically | |
about it being a SUID binary, so this discussion isn't even | |
related to the thing you're accusing them to be hypocritical | |
about... SUID is more than just "code running as root", it's | |
"code running as root in an attacker-controlled environment". | |
That last part is the important one. | |
jpollock wrote 8 hours 33 min ago: | |
By "code architecture" I mean the packaging of their client | |
libraries. | |
This attack demonstrates that they should be tightly | |
focused and have minimal downstream dependencies. | |
I don't have any experience with systemd, but typically, | |
people will bundle _all_ of their client libraries into one | |
.so and say "use that". | |
However, what needs to happen is there should be multiple | |
.so's, one for each sub-API. At least there should be | |
libraries for frequently used shim code (like notifications | |
seems to be). | |
Then systems that need to push information don't need to | |
pull in the dependencies for other parts of the overall | |
systemd interface. | |
I can't think of a reason why pushing local notifications | |
would require a compression library. The notifications | |
should be information heavy already, so not very | |
compressible. | |
As I said, it's a growth and project age thing. One moment | |
you're on one side of a line, the next you have to skill up | |
and do things differently. | |
How the team responds is what is important. That is why | |
people are objecting to the SUID work. Not because sudo | |
isn't a hole, but that the systemd team isn't considered | |
responsive enough to take it on. | |
I know I'm taking lessons from this to my work. It's an | |
unpleasant mirror for me to look in. | |
deng wrote 1 day ago: | |
So that's your best shot against systemd? | |
- Linux packagers decide to patch sshd to use libsystemd for a | |
notification, that could have been trivially done without this | |
library. | |
- libsystemd depends on libzlma | |
- libzlma depends on xz | |
And therefore, systemd is insecure? | |
And what does this have to do with the fact that SUID is a | |
terrible idea that needs to go? | |
James_K wrote 1 day ago: | |
> - libsystemd depends on libzlma | |
> - libzlma depends on xz | |
> And therefore, systemd is insecure? | |
Yes. You have literally just described the way it is insecure. | |
It bundles a large amount of functionality under a single | |
system, and therefore anything using that functionality is at | |
risk. You seem to be suggesting that Systemd would be secure if | |
you didn't use it, which is obviously fallacious. Anything is | |
secure if you don't use it. Systemd offers this functionality, | |
and did it in an insecure way. You cannot blame users for that. | |
Saying that people shouldn't be using a certain part of Systemd | |
is really the same as saying that part shouldn't exist to begin | |
with. The conclusion is obviously that Systemd should be | |
smaller to decrease the chances of things like this happening. | |
Xylakant wrote 1 day ago: | |
LZMA is a widely used compression protocol. The kernel uses | |
it. xz - the compression tool that was affected gets used by | |
the kernel build makefiles - they reference it in the build | |
docs [1] . It's absolutely fair from systemd to have this | |
dependency and to use the trusted library that the most | |
fundamental part of the underlying OS uses. | |
It was purely the attackers choice to leverage the exploit | |
via systemd instead of injecting code in the kernel at build | |
time. | |
[1]: https://docs.kernel.org/staging/xz.html | |
James_K wrote 1 day ago: | |
Your speculation on what is right and what was fair is of | |
no consequence to me. Their error was not simply using a | |
compression library, it was creating a large central point | |
of failure. If Systemd was smaller, it would not have | |
caused this error. By being large, it made itself | |
vulnerable. It made itself a target. It made other software | |
insecure. These facts are inescapable. And you cannot | |
justify this by simply saying they didn't do anything wrong | |
right before the attack, or that packagers are to blame, or | |
that other software might also be vulnerable, or anything | |
else that doesn't address the core of the issue: Systemd | |
created the circumstances needed for this to happen. They | |
were warned of he risks they created, and chose to do so | |
anyway. Now those risks have been made manifest â the | |
inevitable result of a fundamentally flawed design. | |
growse wrote 1 day ago: | |
Why is this an argument specifically against systemd, | |
rather than all large software projects? | |
Linux kernel, gcc, glibc - all bundle "a large amount of | |
functionality under a single system" - does this make | |
their design fundamentally flawed as well? | |
James_K wrote 1 day ago: | |
I think a micro-kernel architecture would be better in | |
many ways, security being just one of them. With GCC, | |
it couldn't really be separated into logically distinct | |
modules any more than it already is. All of the | |
constituent parts essentially use the full | |
functionality of the base compiler part, so there is | |
little to be gained separating them. It's not as if the | |
C compiler from GCC, could for instance, be written in | |
such a way that it doesn't depend on GCC. GLibc is a | |
large implementation, but the library itself doesn't | |
necessarily need to be large. There are some very small | |
libcs out there. | |
On the whole, I do not like monolithic software | |
projects, but I can accept that they are necessary or | |
beneficial in some cases. Systemd is simply a much | |
bigger target than these other things because it is an | |
especially bad example. It has many components which | |
are only tentatively connected. It is also more | |
fixable. Alternate init systems are used much more | |
widely than something like Hurd to replace Linux. The | |
laptop I'm typing this from runs GuixSD which ships | |
without Systemd and I can hardly notice the difference. | |
I doubt a different kernel architecture would provide | |
such a seamless experience. | |
Xylakant wrote 1 day ago: | |
Given how common LZMA as a compression algorithm is, | |
are you certain that your init system of choice | |
doesnât use it in any way? Itâs a very common | |
algorithm in network protocols, itâs a direct | |
dependency of libxml, ⦠- and if any part of your | |
init system uses LZMA, then it just happens not to be | |
affected because the attacker chose to target one | |
specific system. | |
James_K wrote 1 day ago: | |
I wouldn't be affected regardless, because SSH | |
doesn't depend on my init system. | |
Xylakant wrote 1 day ago: | |
The attacker had essentially full control over a | |
very fundamental library in the Linux ecosystem. | |
They could have leveraged that in a hundred ways. | |
The attacker chose to target a very specific | |
component of a very specific system. It was their | |
choice, not some sort of technical requirement | |
that made it impossible to use a different attack | |
vector. Just as they chose not to target other | |
Linux distributions that use systemd. | |
Youâre essentially saying âI was safe because | |
the attacker chose to ignore me.â That worked | |
well this time, but itâs a pretty dangerous | |
stance. | |
James_K wrote 16 hours 53 min ago: | |
When a hacker chooses to attack something, that | |
isn't random. They had to look at a lot of | |
different pieces of software, and decide which | |
would be the best to attack. The choice in this | |
case was Systemd. In other words, if you are | |
looking to do malicious things, Systemd is | |
helpful. | |
Now I want you to imagine that every piece of | |
software has a score, which tells you how | |
useful it is to hackers. Systemd has a high | |
score, and hence it was chosen for this attack. | |
Your argument is that: there are other pieces | |
of software with a high score so it's fine for | |
Systemd to also have one, since without it | |
there would be other things to attack. My | |
argument is that we should reduce the amount of | |
software that has a high score. Do you think my | |
reasoning or your reasoning will lead to a more | |
secure ecosystem? | |
growse wrote 8 hours 23 min ago: | |
The size of libsystemd is immaterial in the | |
case of xz. The attackers had control of xz, | |
and wanted to load it from sshd. | |
There's lots of projects that link xz, big | |
and small. Patching sshd to include any of | |
them would have implemented the backdoor. | |
James_K wrote 7 hours 35 min ago: | |
> But other software is also hypothetically | |
insecure. | |
And I'm sure it'll be the same excuse next | |
time. | |
tgv wrote 1 day ago: | |
First, getting rid of setuid (I guess you'd have to get rid of | |
the whole thing, not just the permission bit) is not the same | |
as making systemd an integral part of the OS. | |
Second, when even the package maintainers can make such | |
"trivial" mistakes, something is wrong. You'd expect a | |
component such as systemd to be much more trustworthy than some | |
random library. | |
I'm not arguing against systemd, just that it seems to grow and | |
grow, and is not the correct place for security. It security is | |
obviously broken. | |
mike_hearn wrote 1 day ago: | |
If it was "obviously" broken why was the xz backdoor such a | |
shock to everyone? Do you personally audit the library | |
dependencies of every tool you run, including core servers | |
that come with your distribution? I think people don't do | |
this. | |
Also, even before the backdoor was discovered, the systemd | |
team were making libxz be dynamically loaded only in the | |
cases where it was needed which would have killed the | |
backdoor dead. There's some evidence that this might have | |
actually caused the backdoor to be sped up and hence led to | |
its discovery. Claims that systemd has bad security have to | |
explain why it was already implementing practices that would | |
have blocked the xz backdoor without it even being | |
discovered. That seems pretty decent to me. | |
tgv wrote 1 day ago: | |
The point is that (even) the systemd maintainers do not vet | |
their dependencies. As an attack vector, it is the | |
(second?) highest level, yet they did not assume the | |
responsibility. Everybody silently assumed they did, hence | |
the shock. | |
> Claims that systemd has bad security have to explain why | |
it was already implementing practices ... | |
No, they don't. It doesn't take away the fact that they did | |
not check xz, and probably only few of their other | |
dependencies. | |
mike_hearn wrote 1 day ago: | |
Nobody was silently assuming the systemd maintainers were | |
reviewing the source tarballs of every dependency for | |
obfuscated back doors. | |
tgv wrote 11 hours 51 min ago: | |
That would be irresponsible and strengthen the case | |
against run0 as a replacement. And let's be honest this | |
time: the argumentation is that it's there to replace | |
sudo. | |
jononor wrote 1 day ago: | |
Package maintainers of a distro can do absolutely anything to | |
a package. With zero input from upstream developers. Some | |
distros have more tradition for patching software than | |
others. An upstream like systemd (or openssh) can hardly be | |
blamed for what others do with their software. | |
deng wrote 1 day ago: | |
> First, getting rid of setuid (I guess you'd have to get rid | |
of the whole thing, not just the permission bit) is not the | |
same as making systemd an integral part of the OS. | |
It absolutely is. sudo allows you to execute code as another | |
user. If you want to do that without giving sudo itself | |
administrative privileges, this has to be done through the | |
service manager, which creates a completely new, elevated | |
process and handles communication with that. This is how it | |
should be done (and BTW, this is pretty much how also the new | |
sudo for Windows works). Now Lennart for some reason prefers | |
systemd as this service manager - you might disagree with | |
that choice, but then come up with a better one. | |
tgv wrote 1 day ago: | |
Decoupling/single-reponsibility is sort of lesson #1 in | |
software engineering. | |
> then come up with a better one. | |
Really? | |
deng wrote 17 hours 31 min ago: | |
> Decoupling/single-reponsibility is sort of lesson #1 in | |
software engineering. | |
Well said. What makes you think systemd does not do this? | |
Have you ever even looked at systemd in any amount of | |
detail? Do you think it is one big binary running as PID1 | |
doing everything? | |
lmm wrote 1 day ago: | |
> - Linux packagers decide to patch sshd to use libsystemd for | |
a notification, that could have been trivially done without | |
this library. | |
Why was that? Would that "trivial" approach have broken the | |
next time systemd made one of their incompatible interface | |
changes, perhaps? Was using libsystemd the kind of thing the | |
systemd maintainers recommended? | |
> And therefore, systemd is insecure? | |
Systems with systemd had a vulnerability that systems without | |
systemd did not. So it certainly seems like systemd-the-system | |
(not necessarily systemd-the-unix-process) is bad for security. | |
mort96 wrote 1 day ago: | |
My understanding is that the UNIX socket based protocol which | |
libsystemd wraps for this specific feature is documented, | |
stable and simple. | |
Xylakant wrote 1 day ago: | |
You're not making a very good point here. A lot of packages | |
have a transitive dependency on liblzma - for example | |
everything that depends on libxml since that depends on | |
liblzma [1] . LZMA is a pretty widely used compression | |
algorithm, I'm absolutely certain there's other juicy targets | |
that depend on liblzma. | |
The reason why "only" sshd on debian/ubuntu was affected is | |
that the attacker chose to tailor their exploit to those | |
systems. Systemd was the vehicle, debian patching opensshd | |
was what made this specific incarnation of the attack | |
possible, but essentially, both trusted a widely used | |
library. | |
[1]: https://packages.debian.org/sid/libxml2 | |
lmm wrote 1 day ago: | |
> A lot of packages have a transitive dependency on liblzma | |
- for example everything that depends on libxml since that | |
depends on liblzma [1] . | |
Sure. But security-critical software like SSH would | |
certainly think twice before bringing in such a huge and | |
complex dependency as an XML parser. | |
> I'm absolutely certain there's other juicy targets that | |
depend on liblzma. | |
You could probably make a system package manager (which has | |
obvious reasons to depend on a compression algorithm) do | |
something nefarious. But that would be a more complex chain | |
of exploitation with more chance for things to go wrong. | |
Most security teams put more attention on security-critical | |
parts like SSH, and I think most people would agree they're | |
right to do so. | |
[1]: https://packages.debian.org/sid/libxml2 | |
viraptor wrote 1 day ago: | |
That looks pretty good. I'm glad that the plan is to make this more | |
typing friendly - systemd-run is not good enough for daily usage. | |
bananskalhalk wrote 1 day ago: | |
I was really hoping the next sudo replacement would borrow heavily on | |
root as role[0] (if not being root as role). Feels like a missed | |
opportunity to not use capabilities. | |
[0]: | |
[1]: https://www.sciencedirect.com/science/article/pii/S01674048220... | |
bandrami wrote 1 day ago: | |
Capabilities aren't guaranteed to be present, and in a lot of | |
high-security situations aren't available (though obviously you could | |
say that about sudo too) | |
bananskalhalk wrote 1 day ago: | |
Sounds exciting and might be obvious, but where will I find systemd | |
and not capabilities? | |
wkat4242 wrote 2 days ago: | |
I'm really starting to hate the sub-community in Linux that tries to | |
constantly change it. | |
I don't want to learn a new network config alternative with every | |
update (Ubuntu changed its net config tool again with 24.04). I don't | |
want an immutable os. I don't want to learn to write new config files. | |
I just want to do what I've been doing but with new packages. If | |
there's a problem with something, just fix it. Don't throw out the | |
whole thing. | |
I moved to FreeBSD and am happy for its reluctance to change. If there | |
is any, it's usually offering something genuinely new to me as a | |
feature and to boot I only need to learn about it if I need it. | |
Hardware support is much lower but it's worth it IMO. I had the same | |
irritation with macOS. Every release breaking something essential that | |
was part of my workflow and i didn't want to change. Eventually I did | |
change but away from Apple. | |
I don't want to change to LennartOS either. | |
ranger207 wrote 1 day ago: | |
> I don't want to learn a new network config alternative with every | |
update (Ubuntu changed its net config tool again with 24.04). | |
That's really just Ubuntu's fault. Between upstart, Unity, netplan, | |
and snapd, Ubuntu likes to go off and do its own thing for a few | |
years before coming back to what everyone else picked in the first | |
place | |
msm_ wrote 1 day ago: | |
>I don't want an immutable os. (...) | |
But I do. So I use one, and contribute to a project that tries to | |
create one. Am I a part of some sub-community that wants constant | |
change? Or do I just have an unusual use-case and want to support it? | |
The beauty of OS is that anyone can decide which tool to use, | |
contribute to it, and even fork it. | |
jauntywundrkind wrote 1 day ago: | |
What complaining. There weren't paved paths before. Whatever one | |
person learned was different from how anyone else did it. Few of the | |
tools had anywhere near the essential capabilities, serving o ly some | |
tiny niche of the use cases in some tool specific limited way. | |
Look at all the different netsevs supported by systemd-networkd. [1] | |
This is a huge list of tools that required a huge assortment of tools | |
to do before, few of which had even part way decent management & | |
fewer still had good init scripts. You used to have to learn from 0 | |
each time, with each tool. Nothing was alike, nothing was as capable, | |
nothing was integrative. | |
Don't listen to these complainers, for God sake. Your life is too | |
short to get pissed off about well built work together featureful | |
tools being built in a mono-repo fashion. | |
I'm so tired of the sabotage, so tired of broadscale general | |
refusenik attitudes. This post is absurd. There was nothing to learn | |
before, everything was 100% special snowflake & distinct. None of it | |
was great, all of it was limited. Systemd mono-repo is built of many | |
small pieces, but they couple together and are 100x more learnable. | |
What you learn today will work across whatever system you run across. | |
It's such a a better world, and these "pry it from my cold dead | |
fingers" attitude can keep to that path for all I care, but I wish | |
they weren't poisoning kinds with absurd incorrect negativity & being | |
such magnets for disdain. The world today is fantastic & you rarely | |
see these folks with even an iota of appreciation for how good we | |
have it, never a drop of balance. But hate sells, & unites, | |
powerfully. | |
[1]: https://www.freedesktop.org/software/systemd/man/latest/syst... | |
lupusreal wrote 1 day ago: | |
> so tired of broadscale general refusenik attitudes | |
You can use whatever software you like on your computers, but | |
you're not entitled to have everybody else follow your choices | |
because everybody else has exactly the same freedom to choose as | |
you do. And if you want to persuade people to follow your lead, | |
name calling is a bad strategy (much less ethnically charged name | |
calling...) | |
jauntywundrkind wrote 1 day ago: | |
The anti-systemd crowd dishes it out like crazy & gets minimal | |
blowback. I'm done letting them be monsters with small minded | |
attitudes, ragging & raging with old crusty attitudes that refuse | |
refuse refuse. | |
I have heard people use refusenik numerous times & never once has | |
it crossed my mind or seemed remotely related to any ethnic | |
matters. There does appear to be a definition though. Alas. It's | |
a great fucking word, makes me smile, feels well crafted & spry, | |
& I detest giving it up, relinquishing it: but I hereby renounce | |
my previous usage & give it up. Blast. Now there is only absence. | |
(Also, usually name calling is bad because your insulting someone | |
for being something. New here, but I don't think refusenik in the | |
ethnic sense is at all slanderous or insulting though? It's a | |
comment more upon the totalitarian state & a contravention of | |
Declaration of Human Rights than it is a comment on the person? | |
So I'm not sure that there's any victims to the modern reuse & | |
repurposing of this word, unlike most terms that had some ethnic | |
aspect. Indeed, the extensive & adaptive history of usage of this | |
word seems to show ever growing rift in meaning from it's | |
original use, & little fear that just because there was an ethnic | |
situation we cannot use it... I begin to think you protest too | |
loudly.) | |
INTPenis wrote 1 day ago: | |
That's funny. It's like there are two camps, conservatives, and | |
progressives. ;) | |
Jokes aside, I just think that life is constant change and the | |
programming industry is a good example of that. Coding practices have | |
improved a lot in the last few years and will continue to improve | |
with new knowledge and new technology. Sometimes it's better to start | |
anew from scratch than trying to adapt old code into new practices. | |
Btw this is not a young whippersnapper saying this. My first IT job | |
was on FreeBSD and OpenBSD. I was a full-time FreeBSD user from 04 to | |
~10. | |
And I remember exacty this gripe back in 2011 when Debian was using | |
one network config, RHEL another. Today I actually enjoy the progress | |
made with systemd, and I'm that annoying co-worker who will give you | |
crap for disabling SElinux. | |
wkat4242 wrote 48 min ago: | |
Well, some things are improvements. But many are not, and are just | |
changed for the sake of it. | |
I'm a fan of SELinux (and the similar mandatory access control on | |
BSD) because it gives strong security but the user or admin keeps | |
control. This is a much better solution than things like immutable | |
OSes where the user can't control anything and just has to trust | |
the developer of the OS. | |
exe34 wrote 1 day ago: | |
I so want to ditch Linux for bsd, but hardware support, both for my | |
current laptop and future pain in searching for compatible hardware | |
is the only thing putting me off. And my server needs cuda for my AI | |
shenanigans, so probably no bsd there either ... | |
paulddraper wrote 1 day ago: | |
It's very fair to eschew change for negligible improvements. | |
But I've also seen the community defend terrible stuff just because. | |
Look at what happened with the init system. System V, fstab, etc was | |
awful. Doing anything with a reasonable level of robustness was | |
grotesquely obtuse and complicated. And yet it was "perfectly fine" | |
to the greybeards. Alternative proposals were near zero. | |
I don't have a dog in the networkmanager/netplan fight. It could be | |
that one is irrelevant; given history, I have a hard time trusting | |
what I hear. | |
sudo has quirks for sure (which is why you see a number of | |
alternatives). | |
chuckadams wrote 1 day ago: | |
Daemontools was pretty popular with greybeards, actually. But | |
yeah, daemontools/runit/s6 and company have always been for | |
handcrafted server setups, where the thing about init scripts and | |
unit files is that they're a standard thing a package can supply | |
and have work out of the box with minimal tweaking across distros. | |
Any serious challenge to systemd nowadays is probably going to have | |
to at least offer compatibility with it. No one is going to rip it | |
all out and start over again (again). | |
andrewstuart wrote 1 day ago: | |
I want the change. | |
I love it when new and better ways are found to do things. | |
I love it that Linux is constantly improving and moving forward. | |
Iâm willing to accept along the way some things seem to be mis | |
steps (Iâm looking at you snap packaging). | |
I love it that improved network configuration systems are being | |
adopted because network configuration is a pain. | |
I love systemd and when new stuf comes out from the systemd project I | |
think âgee Iâm glad finally someone is taking a wholistic look at | |
and fixing that messy inconsistent evolved corner of Linux and | |
replacing it with well thought out powerful and integrated | |
solution.â | |
Bring on the change, change is the best thing about computing and | |
software. I own vintage computers but wouldnât want to live there. | |
JohnFen wrote 1 day ago: | |
> I love it when new and better ways are found to do things. | |
I do, too. But I also really hate it when those new and better ways | |
make things worse for me. Systemd does that in a couple of | |
important ways. There is even some network-related startup stuff | |
that I can no longer make work automatically at all. For me | |
personally, systemd is a regression, not an advance. | |
But I also recognize that the Linux world is not duty-bound to make | |
sure it remains excellent for me, and I've pretty much given up on | |
advocating for my needs in the Linux space. There's no point, | |
particularly with the systemd crowd. | |
cyberpunk wrote 1 day ago: | |
Iâve been running Ubuntu boxes in prod since 12.x â there is no | |
âimprovedâ way to put an ip address on an interface besides | |
writing something to a file in /etc, but every update this file | |
changes, or itâs format does. | |
Itâs bullshit and I wish it would end. | |
Alas, keeps the consultant bucks flooding in when we have to | |
rewrite a load of cfgmgt to go to 24.04 I guess.. | |
iforgotpassword wrote 1 day ago: | |
I just switch every system to systemd-networkd immediately. The | |
same .ini sytax as for service files, and dependencies are easy | |
to handle, e.g. on one system I have two physical Interfaces eth0 | |
and eth1, I want two vlans on eth0, and then bridge one of those | |
vlans with eth1 and then run a DHCP client on that bridge but at | |
the same time assign an additional IP address. This is dead | |
simple to describe with one .ini file per vlan/bridge. Seriously | |
the first time I feel like I'm not fighting an archaic config | |
syntax, fixing up crap in some post-hook.d script, or give up | |
entirely on any config language and just have a convoluted script | |
setting up everything manually. | |
It's also easy to explicitly express "weird" stuff like "run DHCP | |
client and use all the config options except the default route". | |
Seriously a couple times I needed to do dumb shit and was like | |
"there's no way they let you do this" but no, there's a way to do | |
it. | |
And I'm pretty positive the config files will stay stable over | |
the coming years and any new networking features will get | |
appropriate config options in newer versions. | |
cyberpunk wrote 1 day ago: | |
Eh, I could. But I'm quite sure that the method of switching to | |
systemd-networkd also requires the same if not much more | |
maintenance as simply changing the ifconfig template every few | |
years... | |
I really don't care about interface configurations that much. | |
It's an annoyance, but one that's quite easy to fix. I think | |
introducing yet another network configuration here isn't the | |
answer, but my linux fleet just run k8s anyway and network | |
config on the linux level is quite simple before we get into | |
cillium/istio/etc :} | |
iforgotpassword wrote 1 day ago: | |
Sure, I made that choice at a time where after upgrading, | |
Ubuntu suddenly wanted netplan, debian stayed with | |
/etc/network/interfaces and I think fedora went with | |
networkmanager. So I though f- it, they all have systemd so | |
I'll give networkd a spin. And never looked back. | |
So maybe don't just switch out of the blue right now if | |
you've got a working setup, but maybe keep it in mind for the | |
next time. :) | |
pmlnr wrote 1 day ago: | |
> I moved to FreeBSD and am happy for its reluctance to change. | |
Same here on server. Desktop is still linux. | |
dig1 wrote 1 day ago: | |
This is the main reason why I'm still on Slackware. Pat is keeping | |
the same thing for the last 20-30 years. Sure, he had to introduce | |
some stuff, like NetworkManager or PulseAudio, to keep up with the | |
latest software versions, but every major change is postponed as much | |
as possible. Hell, even systemd is not there yet, and I'm pleased | |
about that. | |
metalforever wrote 1 day ago: | |
Same, I am also hiding on Slackware . | |
trallnag wrote 1 day ago: | |
So Slackware is your main OS? Or is it just something to play | |
around with? | |
metalforever wrote 7 hours 27 min ago: | |
Main OS. | |
Rediscover wrote 9 hours 43 min ago: | |
Main here, with *BSDs or Yocto-based right behind. | |
pwg wrote 9 hours 57 min ago: | |
In my case, main, and only, OS. | |
CoolCold wrote 2 days ago: | |
To help myself to understand others better, I made some efforts to | |
look and keep looking outside my bubble. | |
That's not simple though- humans tend to think THEY know better for | |
all others while it's often not. | |
Say you don't want to have immutable distros, but many want. Android | |
or Talos or even OS for network switches are nice examples. | |
Linux based solutions and products related community is wide and to | |
keep up with evolution one needs to adapt and adopt changes. | |
We already see what happens for immutable/stale systems like FreeBSD | |
- even TrueNAS is abandoning it, dying as predicted by experts since | |
2008-2010. | |
On other side - nothing stops you from keep using sudo or even choose | |
disto vendor which doesn't use systemd, there is a choice, not thing | |
set in stone. | |
Say I don't plan to switch to run0 in any near future - first it's | |
not gonna be in any LTS disto, 2nd - it seems to be lacking LDAP | |
based rules and very much likely other important features. | |
hasselhoftd wrote 2 days ago: | |
Agreed. I've taken to treating my linux installs like I used to treat | |
Windows: no internet access expect application specific. | |
For example, I run a Visionfive 2 OpenBSD install with squid, | |
everything else has to go through that. | |
cyberpunk wrote 1 day ago: | |
Curious why squid and not pf? | |
Khaine wrote 1 day ago: | |
squid is a http(s) proxy and pf is a firewall. They do not do | |
the same thing. | |
cyberpunk wrote 21 hours 20 min ago: | |
I assumed it wasnât doing tls interception as simply using it | |
to allow/disallow internet traffic from various internal hosts | |
â pf works for that also. | |
Relayd also does a bunch of similar things and is closely | |
integrated with pf too.. | |
Khaine wrote 20 hours 10 min ago: | |
That's fair. I assumed he was using squid to filter/block | |
ads and dodgy websites. You can also kind of do this with | |
pf, but not as well. | |
cyberpunk wrote 18 hours 32 min ago: | |
I use openbsd for that purpose also, but with unbound :} | |
Khaine wrote 14 hours 38 min ago: | |
I used to do something similar with pf, unbound, and | |
squid but on freebsd. | |
TacticalCoder wrote 2 days ago: | |
> Or in other words: the target command is invoked in an isolated exec | |
context, freshly forked off PID 1, ... | |
Of course. The solution to every Linux "problem" is, of fucking course, | |
to have the PID1 spread is tentacles to yet more part of Linux. | |
Every single problem can be solved by giving yet more power to PID1... | |
Except the problem of PID1 having too much power. | |
CoolCold wrote 2 days ago: | |
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. | |
segasaturn wrote 1 day ago: | |
How hard would it be to create a program to send a signal to polkit | |
"impersonating" run0 and obtains a root shell? :) | |
YtvwlD wrote 18 hours 11 min ago: | |
You'd need to be root already, so hard. | |
gh02t wrote 1 day ago: | |
Is that even a problem? Any program can shell out to sudo, hence | |
why you shouldn't set NOPASSWD in sudoers. Polkit takes in a | |
request on an unprivileged interface, that request is evaluated in | |
privileged code against the set of privilege rules, and then passed | |
the proper capabilities if the rules allow. This includes a | |
mechanism where it can, if desired, prompt a user to enter a | |
password etc to prevent a rogue program silently acquiring root. | |
But even in the worst case, the rogue program is not going to | |
acquire any capabilities that you would not otherwise have as with | |
sudo, and the breakpoint between privileged and unprivileged code | |
is (in theory) more tightly defined and controlled. | |
<- back to front page |