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.

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.

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.

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?

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.

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.

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.

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

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

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.

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.

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.

As if marketing alone could do that. Poettering does seem to be, to a casual observer, kind of a dick. Arrogant, dismissive of competing products... kind of like that other guy — also kind of a dick — who supposedly had that "reality distortion field" that hoodwinked all those poor saps into buying his phones.

There's no fucking way in hell you are able do that if the user base doesn't think the product is good. To those saying it, I always reply, "It may not be the product you want, but a shitload of people disagree with you, quite obviously."

I'm not personally a huge fan of the iPhone or systemd. But they are both clearly "the best" for the largest number of people. (And that is even clearer for systemd, as it doesn't cost hundreds or thousands of dollars more then the competing products.)

just that his vision was garbage, and everyone knows. but he stood by it. and nobody was putting the same energy he was to either offer better or stop it (rejecting bad ideas also take energy. see gnome deep dive into garbage as another example)

Linux is mostly made from scraps (eg Bluetooth and wifi entire stacks) or misguided but funded things. the age of scratching own itch is mostly gone

which is a big part, but not the one most people complains about.

the actual UX is very much windows like.

Run0 builds character. :^)

Your comment was really well expressed btw. Made your thoughts and emotions very clear about this. Inspiring communication skill! :)

This is not the case at all. The vast vast majority of Linux installs are on servers.

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.

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

What is being announced is merely a thin layer of cmdline syntactic sugar over an existing feature, to make it closer to sudo in usage.

So I'm not sure what exactly you were missing?

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.

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.

It sounds like a great use of systemd, for those who want to use it.

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

Incorrect, because nowhere in the IPC dance are these components exposed to the same untrusted environment as they are with sudo.

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.

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

This is an interesting offhand comment. You could implement a very similar tool by SSHing to localhost.

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.

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.

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.

would something like PermitRootLogin=localhost punch an enormous hole in your intricate opsec?

There's so ways to configure access to a system, each with footguns I'm surely unaware of.

> ssh user@privileged-commands ./do-something

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.

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

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

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.

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]: https://lkml.org/lkml/2014/4/2/580

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.

Poettering and Sievers are skilled devs with huge egos.

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]: https://www.millert.dev/

Y'know. Before some strangely-named benefactor from within the UTC+03:00 time zone swoops in.

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.

Remember, malware can just alias your sudo command to one that logs your password and piggyback on your next use. If you ever use sudo, then all bets are off on sandboxing malware. Best to not have a ladder to root at all.

Sudo is a crutch for people that have not learned the last 20 years of privilege isolation tech.

I was under the impression that ‘sudo’ was baked into the entire system. Like ‘cd’ or ‘ps’. How exactly can you just swap out sudo? Does that involve swapping out chmod as well?

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.

- 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

"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 https://gtfobins.github.io (or the Windows NT equivalent LOLbins) if you wanna know how many binaries there are as an attack surface.

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.

As long as this keeps happening due to the concept failure of how shared libraries are used for both active development and runtime execution, there won't be an easy fix available.

The stubborness of C++ developers not seeing that there is two kinds of different users, devs and endusers, is what also annoys me a lot. I understand their intent to make development and debugging easy.

But honestly, that should not be the job of the developer of a library and rather be part of the development toolchain. If the toolchain cannot fulfill this need, then the concept of binary distribution itself (aka FFI/C ABI/ELF) is wrong and needs to change.

The "never change C" mentality is what got us here, where hundreds of developers rewrite everything in Rust/Go/Zig, hoping that there is an end in sight...only to realize that at some point they have to build a different OS from the ground up to actually be able to really fix it.

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.

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.

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

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.

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.

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.

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.

Anyway, I have been using doas instead of sudo for a while on servers, it’s rock solid if you don’t need some of the more advanced features of sudo.

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

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.

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?

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.

Hence all containers are isolated from each other, not only at process level, but at user + cgroup level too.

Apptainer: https://apptainer.org

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.

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.

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.

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.

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

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.

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

Alternatively, containers really are a no-thinking-required solution. Everything maximally isolated by default.

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.

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;

Some more complex software might require more configuration, but most of the time user and group setup is not part of that.

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.

Also, people noted HPC, and other still very relevant scenarios.

[I'm all for replacing notions of privileges/permissions with capabilities.]

In the cloud, AWS/GCP let or not let an IAM user reach a server.

Nothing worse than ansible with its “sudo /tmp/whatever.sh” which hides what it’s doing.

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`` }.

You can also disable it in the sudoers file.

I'm not sure different passwords adds more protection for single-user machines, especially when sudo(1) can spawn root shells!

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.

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.

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.

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.

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.

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.

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

https://mate-desktop.org/

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.

https://en.wikipedia.org/wiki/Spatial_file_manager

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.

I suppose I should say I found Gnomes luridly chunky decorations and widgets to be personally offensive.

GNOME offering a monolithic environment with heavy opinionation is the opposite.

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.

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.

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.

The terminal line should be clean between XMODEM at the terminal emulator and at the client end.

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

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)

* 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

On a more serious note, I wonder what random ASCII escape sequences we can send.

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] https://github.com/systemd/systemd/blob/main/man/run0.xml

[1] https://en.wikipedia.org/wiki/ANSI_escape_code#SGR_(Select_G...

> back when I used linux

What do you use now? :0 BSD? Plan 9???