Email or username:

Password:

Forgot your password?
Lennart's posts Post Back to profile
Top-level
Lennart Poettering

… entirely, for example this stuff:

ruderich.org/simon/notes/su-su

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. (If you don't like this, …

29 April at 7:54 | Open on mastodon.social
50 comments
Lennart Poettering

… you can easily turn it off via the --background= switch). It also inserts a red dot (unicode ftw) in the window title while you operate with privileges, and drops it afterwards.

And since it's just systemd-run called under a different name it supports the --property= switch that systemd-run supports, i.e. it allows you to set arbitrary service settings for the invoked privileged command/session if you like.

Anyway, that's all for now. Enjoy "run0"!

29 April at 7:57 | Open on mastodon.social
Stephan Herbers

@pid_eins When you say "while you are operating with elevated privileges", do you mean you can use run0 to create a root shell to work in, or do you just mean while the current programm I started as run0 ist running?

29 April at 8:00 | Open on mastodon.sherbers.de
Lennart Poettering replied to Stephan

@stephan not sure I grok what you are saying. run0 can invoke a shell as root for you, but can also invoke any other command you like as root. The shell is after all just a program too. A program that is typically used to invoke further programs, but still just a program.

Regardless what you precisely invoke: run0 will tint the bg of its output (and your input) in a reddish tone. Once the program terminates this tinting ends, and you get your usual black (or white or whatever) background back.

29 April at 8:08 | Open on mastodon.social
Stephan Herbers replied to Lennart

@pid_eins Yes that explains it. I kinda forget that running a shell is also just running a programm. Looking forward to run0.

29 April at 8:11 | Open on mastodon.sherbers.de
Sandor Szücs

@pid_eins wow the auto coloring and title changes would be really annoying. The config to disable it seems to be not user friendly, too:
--background=switch
Whatever background means in this case and why it’s correct to set to switch seems like arbitrary to me.
The tool itself seems to be indeed great!

29 April at 8:10 | Open on hachyderm.io
A Manzer replied to Sandor

@sszuecs @pid_eins I think it's the switch that is called `--background=`. I don't think the thread described the different settings you can give to --background.

29 April at 10:57 | Open on techhub.social
Lennart Poettering replied to A

@amanzer @sszuecs oh. i didn't grok @sszuecs's comment, I was sure there was some misunderstanding but I couldn't figure out how! But your explanation explains the misunderstanding perfectly! So yes, the switch is called "--background=" and you can override the background color with that, or you can assign an empty string to disable the tinting altogether.

29 April at 11:31 | Open on mastodon.social
A Manzer replied to Lennart

@pid_eins @sszuecs Next up, adding "--background=magenta" to my run0.rc. 😂

29 April at 11:44 | Open on techhub.social
Lennart Poettering replied to A

@amanzer @sszuecs note quite. we expect ANSI color specifications, hence you probably want --background=35

29 April at 12:51 | Open on mastodon.social
third="Beedell", first="Roke" replied to Lennart
Lennart Poettering replied to third="Beedell",

@rokejulianlockhart because this is about terminal output, and terminals eat ansi sequences and have no concept of alpha channels?

30 April at 16:20 | Open on mastodon.social
Reto replied to Lennart
@pid_eins @rokejulianlockhart well, modern terminals have true color support at least... would've been nice over the plain ansi number but I get it that querying the cap might be annoying.
30 April at 18:17 | Open on pleroma.labrat.space
Sandor Szücs replied to Lennart

@pid_eins @amanzer haha, ok so basically—background=<color>
Ok 👌

29 April at 13:24 | Open on hachyderm.io
TheStroyer

@pid_eins I think it's a good take one sudo. I think there were some vulnerabilities found in sudo recently, so it's good to look at other ways to do it.

I wonder what the adoption of this tool is gonna be. Just very pragmatically, the name run0 is harder to type than sudo. So you would have to make a shell alias. Would it be possible for a distro to completely replace sudo with this and create an alias by default? Maybe it would need to get a compatibility mode for it to replace sudo

29 April at 8:12 | Open on mastodon.social
Lennart Poettering replied to TheStroyer

@TheStroyer the command line of run0 is intentionally kept close to sudo's. But that's were the compatibility really ends, i.e. /etc/sudoers and so on we're never going to add compat for.

From my perspective run0 should be fine already for a distro to replace sudo with. But let's see how this plays out, I am pretty sure there might be a feature or two we still need to add before the first distros decide it's ready to switch over.

And I am pretty sure there are plenty of distributions…

29 April at 8:17 | Open on mastodon.social
Lennart Poettering replied to Lennart

@TheStroyer … which think that things like pluggable client-side modules, LDAP and so on are actually a good thing, even though I would vehemently disagree with that.

29 April at 8:18 | Open on mastodon.social
Dave Anderson replied to Lennart

@pid_eins Same disagreement here. But also iirc policykit is extensible right? So if someone is brave enough they could probably extend pk with whatever things they want, and then it can apply to all privilege escalation not just run0!

Maybe I shouldn't give people ideas...

29 April at 8:26 | Open on hachyderm.io
Lennart Poettering replied to Dave

@danderson PK is scriptable with JS, so people kinda can do any kind of shit with it, of course. But I think it's much less problematic than what sudo is doing, because PK runs that stuff in a well defined execution context forked off PK's service which runs unprivileged – and not on the client side, in an icky, undefined, half-inherited mess of an execution context under user control – like sudo does it.

29 April at 8:30 | Open on mastodon.social
Dave Anderson replied to Lennart

@pid_eins 100% yes. N:M dlopen() in unpredictable contexts should really go away as a plugin mechanism, it's so easy to create massive problems.

I saw some distros try to fix PAM this way too, they (ab)use the nscd caching protocol in glibc to move all lookups into a system daemon, and hide the .so's from the rest of the system. Same idea, move all the scary plugin stuff to a central location where you can manage it more safely.

29 April at 8:53 | Open on hachyderm.io
Dave Anderson replied to Dave

@pid_eins Looks like there was a short discussion on the glibc ML in 2022 about formalizing this interface and explicitly support the privilege separation use case, but I'm not sure if anything more happened since...

29 April at 8:54 | Open on hachyderm.io
Lennart Poettering replied to Dave

@danderson from my perspective as a systemd person I wouldn't ask for that from glibc. We have nss-systemd these days which is an IPC frontend to the generic varlink IPC API described here:

systemd.io/USER_GROUP_API

Anyone can plug in their stuff there. It's generic, extensible and IPC based. Unless you are a systemd hater I see no reason why we'd need to shove that into glibc.

29 April at 9:13 | Open on mastodon.social
Dave Anderson replied to Lennart

@pid_eins Ooh, TIL! I didn't know about this entire subsystem of systemd. My worry was going to be what to do with the cursed legacy modules that some people have, but I see with userdbd there's bidirectional compatibility between varlink and nss clients. Very nice, and yes I agree this is a better way to set up the system.

I look forward to the posts for next release, I'm even learning stuff about older releases!

29 April at 9:42 | Open on hachyderm.io
Simo ✔️ replied to Dave

@danderson @pid_eins if later systemd is not enough sssd has provided this service with proper caching for almost 15 years.

It was built specifically for 3 reasons: consistent caching, remove unwanted libraries from binaries, allow centally controlled private credentials.

Because it predates systemd it has its own protcol but also a fast, mmaped shared cache that avoid process context switching when not needed.

(full disclosure I am the original author).

29 April at 12:22 | Open on fosstodon.org
TheStroyer replied to Lennart

@pid_eins So the intention for it to be a replacement for sudo right? I.e. sudo does not need to be present on a system.

29 April at 8:30 | Open on mastodon.social
TSRBerry replied to Lennart

@pid_eins Could you expand on the LDAP thing?
Are you saying LDAP is a bad thing in general or how authentication works with it?

30 April at 21:11 | Open on ravenation.club
leo vriscrab² (homestuck) :dado_verified: replied to TSRBerry

@tsrberry @pid_eins i assume it's referring to how the LDAP implementation ends up running in-process in everything that uses NSS (in the absence of nscd/etc) instead of in its own daemon?

30 April at 21:44 | Open on 60228.dev
Josh Triplett replied to Lennart
> the command line of run0 is intentionally kept close to sudo's.

Could we get a -E/--preserve-env switch? (It'd also be nice if users can do per-user configuration to set that, or to set a variety of specific environment variable passthroughs.) There are a variety of environment variables that are useful to pass through, and I'd rather not specify them all every time or do configuration-via-shell-alias.
29 April at 17:27 | Open on social.joshtriplett.org
jasmin

@pid_eins ooooh, that's nice! thanks!

/cc @ytvwld you might be interested in run0 as well ^^

29 April at 8:26 | Open on queer.group
verbumfeit

@pid_eins How would one check, within a bash script, if it was executed with run0?
Verifying the same for/with sudo always felt confusing to me, with countless different ways to do it, each one less readable than the previous..

29 April at 10:21 | Open on fosstodon.org
Lennart Poettering replied to verbumfeit

@verbumfeit sudo sets a bunch of env vars, and we set the same (i.e. SUDO_UID/SUDO_GID/SUDO_USER), for compat.

29 April at 10:22 | Open on mastodon.social
Jann Horn

@pid_eins yesss this is great, thank you. it would be really nice if NO_NEW_PRIVS was more widely used, and I think daemon-based sudo is a big step towards that...

29 April at 10:44 | Open on infosec.exchange
Scott Leggett :fedi: :golang:

@pid_eins It sounds like a great improvement on sudo, but I have a question: how do you pronounce "run0"?

29 April at 11:55 | Open on fosstodon.org
Lennart Poettering replied to Scott Leggett :fedi: :golang:
bluca replied to Lennart

@pid_eins @smlx surely "run-oh", pronounced with a heavy Italian accent and related hand gesture

29 April at 14:44 | Open on fosstodon.org
Nekko replied to bluca
Matěj Cepl 🇪🇺 🇨🇿 🇺🇦 replied to Nekko

@NekkoDroid @bluca @pid_eins @smlx You know this logo (and the clip of “Forever Young” by Alphaville) are quite problematic in many nations, right?

29 April at 20:09 | Open on floss.social
Nekko replied to Matěj Cepl 🇪🇺 🇨🇿 🇺🇦

@mcepl @bluca @pid_eins @smlx

No I indeed don't know because I don't keep up with car companies and what they do.

29 April at 21:30 | Open on mastodon.gamedev.place
third="Beedell", first="Roke" replied to Matěj Cepl 🇪🇺 🇨🇿 🇺🇦

@mcepl, so? It's the symbol of a car manufacturer. That's the context it was being used in, and that's all that matters consequently.

30 April at 14:56 | Open on mastodon.social
Matěj Cepl 🇪🇺 🇨🇿 🇺🇦 replied to third="Beedell",

@rokejulianlockhart

Ask some of your Central European or Eastern European friends.

30 April at 20:50 | Open on floss.social
Lioh replied to Lennart
Fluchtkapsel replied to Lioh

@Lioh
Danke, jetzt habe ich wieder einen Ohrwurm.

We don't talk about run0! (youtu.be/bvWRMAU6V-c?si=UUIfTl)
@pid_eins @smlx

30 April at 5:30 | Open on nerdculture.de
irina 🌷🐇 replied to Lennart

@pid_eins how set-in-stone is the name?

i've seen a couple people bring up concern about such a frequently used command needing the user to reach to the number row, and runz (run zero), runa (run as), or rune (run elevated) thrown around as suggestions.

30 April at 15:22 | Open on eldritch.cafe
Lennart Poettering replied to irina

@irina we have been going forth and back on this internally, we are not going to reopen that can of worms, sorry. Its a bit bikesheddy at this point...

30 April at 16:22 | Open on mastodon.social
paštika

@pid_eins What about emojis? Everyone loves emojis!

30 April at 8:38 | Open on kompost.cz
Tobias Klausmann

@pid_eins One request: _please_ also ship documentation (manpage, whatever, something easily findable) on how configure polkit/run0 to do common sudo patterns like "Allow wheel to do sudo -i with password". "Allow that user to run this _exact commandline_ without password; and this other command with any parameters".

By now, I know how to do these things with sudoers, but a big barrier to using run0 at least for me would be having to learn all of those patterns in polkit.

30 April at 15:38 | Open on mas.to
Tobias Klausmann replied to Tobias

@pid_eins And also: "remember I typed my password five seconds ago" and "forcefully expire said knowledge".

30 April at 15:43 | Open on mas.to
masterleep

@pid_eins One thing I do with sudo is allow a less privileged app process to invoke an nspawn container to run a sandboxed command. But the command is only known at runtime. I wonder if there would be any way to do that with run0.

30 April at 17:09 | Open on sfba.social
squalouJenkins

@pid_eins

Very interesting !

On some servers I configured sudo in order *not* to allow to run for instance : sudo bash, or sudo sh, or sudo su by the way.

Is this kind of control possible ? I must admit last time I touched polkit was decades ago.

30 April at 18:48 | Open on fosstodon.org
Dusk (ponies!)

@pid_eins Would it be feasible for `run0` to have an option for creating a login session, including spawning a user D-Bus session, similar to `machinectl shell root@.host`? E.g. `run0 --login` or `run0 --shell`.

I've been using `machinectl shell alice@.host` over `sudo -s -u alice` for a while, but it's hard to recommend that when machinectl(1) isn't reliably available (Fedora at least sticks it in the non-default [systemd-container](<packages.fedoraproject.org/pkg>) package), and when the invocation is so much more verbose.

@pid_eins Would it be feasible for `run0` to have an option for creating a login session, including spawning a user D-Bus session, similar to `machinectl shell root@.host`? E.g. `run0 --login` or `run0 --shell`.

I've been using `machinectl shell alice@.host` over `sudo -s -u alice` for a while, but it's hard to recommend that when machinectl(1) isn't reliably available (Fedora at least sticks it in the non-default [systemd-container](<packages.fedoraproject.org/pkg

30 April at 22:31 | Open on pony.social
Go Up