Run0, a systemd based alternative to sudo, announced

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.

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

I can think of a number of things this tinting would break.

Can you name any?

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.

I think it's more that the default seems backwards than the lack of ability to change it.

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.

True, I was thinking a simple environment variable or systemd configurable would be fine but I guess an alias is a good idea.

The user's choice of color schemes.

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

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.

"Defaulting to on" is just a symlink to an existing binary so that's not really much a problem.

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.

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

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.

Any sane command line program will only output color codes if isatty(STDOUT_FILENO) succeeds.

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.

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.

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.

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.

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

'alias' is your friend.

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

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

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.

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.

Eh.

`alias grep='grep --color=auto'`

`alias ls='ls --color=auto'`

It's canon.

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

Is xmodem still used outside of computer museums (including private computer museums)?

It's e.g. still very popular with embedded development. One example: u-boot supports it.

It is the easiest way to upload an image to u-boot, as it does use the same terminal, thus there is no need to set up a secondary path; If you can talk with the u-boot CLI, you can also upload with xmodem.