481–490 of 902 posts
Earlier quoted context omitted.
You only have one admin? How do you know who logged in, ssh certificates?
Only one human per machine. If you need to share the machine, make multiple containers and give everyone a separate container.
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 pr…
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.
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…
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
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.
Earlier quoted context omitted.
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.
Counterpoint: GNOME and the modern GTK framework (I needn't say more.)
> 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.
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…
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.
Earlier quoted context omitted.
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.
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
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.
> 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.
It's the usual way to make changes to a privileged file in Emacs; ssh to localhost with root.
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 pr…
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.
Earlier quoted context omitted.
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 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.
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.