Sudo or run0 ?
Posted by elementrick@reddit | linux | View on Reddit | 173 comments
What's your take on the subject? Been using sudo for years but lately i'm mostly running run0 and i like it. Even considering adapt my scripts to use run0 since i'm on a compatible distro. Does it make any sense to not even set up sudo anymore in the first place?
Sataniel98@reddit
run0 seems like a solution to a problem I don't have
noworkdone@reddit
Its a solution to a problem every linux distro had until a few mo tha ago, assuming I understood how the Copy Fail vulnerability worked.
Never the less, sudo has been the source of many vulneravilities over the years.
RudahXimenes@reddit
Copy fail was a flaw in how page cache was stored and affected the
sucommand. This is different fromsudoBut you're right, sudo had many vulnerabilities in the past. Despite it, it's very well maintained
BashfulMelon@reddit
It worked with any
setuidbinary, whichsudois.1esproc@reddit
so the source of the issue isn't the sudo binary, it's the entirety of setuid's architecture? so replacing sudo with run0 doesn't fix the problem, because your system is probably full of other setuid binaries
csjewell@reddit
It's one less... Each one is progress.
RudahXimenes@reddit
I could not found any information about it online. All places I looked said that it was a failure in how the kernel handles page cache and how it overwrites some data in memory bypassing the
sucommandCan you send me your sources so I can understand it better?
BashfulMelon@reddit
My source was understanding how the exploit worked which I know isn't very helpful to you lol
There is a small thing about it on https://copy.fail/
RudahXimenes@reddit
Well, so run0 does not mitigate it at all. Even pkexec is on the list, which is essencially run0
It only reinforces that the issue is a lot deeper than sudo or something else
daemonpenguin@reddit
In order: Yes it does. Not, it isn't. You misunderstand what run0 is and how copyfail worked. The point of run0 is that it is not setuid.
noworkdone@reddit
Does run0 use pkexec itself or just its confoguration format ?
RudahXimenes@reddit
I just read an article explaining it better. Both run0 and pkexec uses polkit to authenticate the user, however pkexec uses a setuid method to escalate privileges, like sudo does, while run0 asks the system to run an application as root, not needing privilege escalation
run0 does not run pkexec and I was wrong
DerfK@reddit
Then the question becomes, who validates the policy/permissions in this case, run0 or systemd? If its run0, how does systemd know its talking to the real run0 and not a copyfail version that tells systemd "trust me, polkit totally says
nobodyis authorized to run bash as root"?Actually, I wonder if the exploit only affected executables, or if it could have placed an /etc/shadow with a known root password into cache. Or replaced polkit config with a policy that everyone can do anything?
RudahXimenes@reddit
Well, that's a deep dive. I dont know to answer those questions. Why dont you research that and explain it to us?
Literallyapig@reddit
while run0 could mitigate this issue, `su` is part of the `util-linux` package, which is installed by default in essentially all distros and provides other essential commands like `blkid`, `fdisk`, `mount` etc. so unless you go out of your way to either remove the `su` binary or restrict its usage, using run0 wouldn't help you much.
1esproc@reddit
It doesn't mitigate it because all those other tools are using setuid, and that is fundamentally different from
su/sudo. You're not going to remove setuid capability from your system nor all the setuid binaries on it just because you're using run0 instead ofsudoteleprint-me@reddit
Its solves the exploitable privelage escalation problem. A root process launches privelaged processes while ghe rest live in user space rather than escalating a user space application to root or kernel space.
DFS_0019287@reddit
It's a different attack surface. run0 uses polkit for authentication, and I believe there have been some vulnerabilities in that in the past.
kaszak696@reddit
Polkit also uses an unmaintained JavaScript engine to do it's thing, lack of maintenance + dealing with elevated privileges is a spicy combination. At least it's a simple one, not something horrifying like V8 or Spidermonkey, but still...
chocopudding17@reddit
But it's also important to note that the JS engine only parses trusted input--admin-controlled rules.
nixcamic@reddit
Why... why does policykit use a javascript engine?
BashfulMelon@reddit
It allows sysadmins to put logic around authorization rules. It's fine.
nixcamic@reddit
It just seems like there are lots of maintained JS engines, granted, often browsers make breaking changes cause they don't care that much about users outside of the browser. But there are maintained scripting languages that are designed to be embedded, like Lua. Seems like it would make more sense to use something like that.
teleprint-me@reddit
Yes, polkit has had cves in the past. thats why i said it depends on your pov, but thats its the way its framed. not claiming one method is better than the other. when i have my way, which i will, im dumping systemd.
1esproc@reddit
What do you mean by this...? What are you waiting for?
tajetaje@reddit
Eh, still smaller. You have to have polkit running (usually), you don’t have to have sudo
granadesnhorseshoes@reddit
Just robbing Peter to pay Paul. Now there's a whole allocated PTY and a bunch of IPC between service manager, the users TTY, the new PTY, and god knows what else.
The issue with copyfail or dirtyfrag wasn't setuid, it was in being allowed to dick with in-kernel file descriptors. It may have been entirely feasible to fuck with a run0 pty file descriptors with the same type of exploit. Perhaps in even more nefarious ways than a simple privilege escalation.
WoomyUnitedToday@reddit
sudo. I hate the popup box run0 does
DFS_0019287@reddit
Yes. I tried run0 for the first time a couple of minutes ago and was surprised by that. Just because I'm running a graphical desktop, it doesn't mean I want a terminal command to open a graphical password prompter. Just do it in the terminal itself.
EtherealN@reddit
I just tried that for the first time and... what in the actual... O.o
Fortunate for me that the only thing I have with systemd on it is the gaming desktop (everything else is either Chimera or OpenBSD), because yikes this is a silly "feature".
RudahXimenes@reddit
I know that if you're running with no GUI, it works all in tty, just like sudo.
I don't know if there is a way to force this behavior when you have GUI
syklemil@reddit
There must be, because I didn't even know
run0has a graphical login prompt option, and I've only ever used it on desktop terminal emulators.DFS_0019287@reddit
Yes, I tried it on the console and it prompted in the terminal. There are ways to force that even in a GUI, but they are pretty hacky, IMO. And because of the architecture of run0 and polkit, it's probably hard to change that behavior.
RudahXimenes@reddit
Well, that's a shame on run0... I like text authentication as well
Rincepticus@reddit
Wtf is run0?
Perokside@reddit
Systemd's v256 alternative to sudo to move away from suid binaries (sudo).
zlice0@reddit
that just sounds like switching to root with extra steps
eredengrin@reddit
If anything, I'd say it's more like switching to root with less steps, not extra steps.
suid binaries have a lot of edge cases, so there's a good reason to get rid of them. If I'm not mistaken, some of the recent vulnerabilities in the kernel were related to suid binaries. Lennart wrote more about the reasons for run0 on this mastodon thread. Also, sudo itself is quite complex and supports way more features than the average user requires, so having a smaller and simpler alternative further reduces the attack surface.
singron@reddit
If you mean the recent page cache attacks, it's merely easier to write an exploit for a suid binary, but you could do the same for any binary that runs as root and is readable by an untrusted user, including e.g. systemd. Minimizing suid in general still seems good though.
panick21@reddit
Its actually more like android, its arguably a better way to do it.
cathexis08@reddit
Basically.
ElectronicFlamingo36@reddit
Can somebody stop this systemd madness please ? 😃
throwaway234f32423df@reddit
2011-era comment
ElectronicFlamingo36@reddit
2011-era response 🤣
edward_jazzhands@reddit
Peak Linux pretentious
nonFungibleHuman@reddit
Unix*
outer-pasta@reddit
systemd is really a Linux thing.
AdvisedWang@reddit
Sudo has a lot of unnecessary complexity for a setuid root binary, which has resulted on major security issues both due to vulnerabilities in sudo itself and the inevitable misconfiguration of a complex software. Run0 solves an actual problem. Who cares who wrote it. In fact, that all actually raises my opinion of systemd.
fgiancane8@reddit
This is the perfect answer. Maybe in the future sudo can symlink run0 ahah
tristan957@reddit
systemd is a software project to create the basic utilities to make an operating system. Why would they stop? It's their goal.
StephaneiAarhus@reddit
How about they do it instead of phagocyting the whole GNU base ?
MeDerpWasTaken@reddit
sudo isn't even a GNU tool, and if they can make a better version of something I don't see the problem with doing so
TCIHL@reddit
Amen. Preach!
Kilobyte22@reddit
Reducing suid binaries is actually a very good solution, and in a perfect world they would not exist at all.
They offer so much attack surface simply by the fact that the user fully controls their environment allowing them to trigger very weird code paths.
As an example: put it in a cgroup and limit its memory so that an allocation fails. Maybe it now starts executing instructions from environment variables even though you would not usually be permitted to use it? run0 by design cannot be exploited that way since it never has any higher privileges than the user running it.
D0nkeyHS@reddit
Can you stop your biased hate?
SoggyWalrus7893@reddit
I was wondering that also. I just set a password for root and use su (old habit from UNIX)
MrcarrotKSP@reddit
I use both Linux and BSD, so it's sudo every time. Not retraining my muscle memory and rewriting scripts for something that only works on some of my systems.
EtherealN@reddit
I use both Linux and BSD, so it's doas every time. Not retraining my muscle memory and rewriting scripts for something that only works on some of my systems.
😛
TwystedLyfe@reddit
doas works on Linux and BSD and so far has a much better security track record than sudo.
MrcarrotKSP@reddit
That's true, but the systems I own are generally not ones where I have to be concerned with that kind of thing. I use sudo because I'm used to it and know how to configure it.
RudahXimenes@reddit
Maybe he can adapt his scripts to assess if there is systemd and run0 installed, if so, keep with run0, otherwise sudo. He can even keep going and try with doas and su as well
tblancher@reddit
Writing scripts that use sudo (or run0)? You're doing it wrong. My belief is that sudo is for interactive, authorized privilege escalation.
I haven't switched to run0 (or doas) since I don't have a compelling reason to. To my knowledge sudo is not deprecated, so I see no reason to switch.
nandru@reddit
At this pojnt, is better to ask ourselves if we need to rename GNU/Linux to GNU/Systemd/Linux
DGolden@reddit
Just
su -;-)Sure you're only going to end up doing a
sudo su -in the end if you have usesudoanyway....exhaustedexcess@reddit
Sudo. It’s all I’m familiar with using Debian stable
kittymoo67@reddit
sudo is love sudo is life
DoubleOwl7777@reddit
sudo. if it aint broken, dont fix it.
noworkdone@reddit
It kinda is, that's the point.
DoubleOwl7777@reddit
works fine for me.
panick21@reddit
Disabling all security and giving all users access to everything also 'works for me' doesn't mean it would not be 'broken'.
TwystedLyfe@reddit
run0 only works on systemd which means it only works on Linux.
doas from OpenBSD has been around for a while now and yes there is a Linux port too. Much simpler to setup than sudo, a much smaller binary and attack surface.
panick21@reddit
True, and I use it too, but it doesn't solve the fundamental issue any different then sudo.
The_Real_Grand_Nagus@reddit
I avoid all systemd NIH solutions
panick21@reddit
It actually literally integrates with something else. that already exists. and its not NIH if you have a good security reason to do it.
luzidd@reddit
run0 isn't a drop-in sudo replacement yet, i wish it was.
It can't match specific programs or command lines in Polkit rules. pkexec has this via action annotations, but it's a little messy.
It's also not suited to use with namespaces. run0 aims for ssh-like semantics, meaning it won't inherit caller namespaces (mount, network, etc.). sudo/pkexec inherit context—which is risky but practical in chroot/container setups.
whosdr@reddit
Ohh, the namespace issue could well be a dealbreaker for me. I use mount-isolated namespaces in the way they describe, using bind-mounts. (I get up to some fun stuff.)
luzidd@reddit
Would you like to share the fun stuff you're getting up to with you mount namespacee? :D
whosdr@reddit
Only hints. It involves root-owned namespaces, suid binaries, bind-fs and sometimes encrypted filesystems.
JackedInAndAlive@reddit
I find
run0 --empowerreally cool. It gives you root capabilities, but keeps the current user id. For example, it won't create files owned by root in your home directory, which probably happened to many of us.ThomasterXXL@reddit
Now that is great! This is what I feel the default use case should have been.
But... I'm gonna have to upgrade to Fedora 44 to use it... or risk the fun side effect of only upgrading only a subset of core system packages between different distro versions...
whosdr@reddit
This is something I had to learn about when researching how suid binaries work.
There's the Real User Id (ruid) and Effective User Id (euid). And the latter is what dictates the permissions you have.
And just for fun, it means you can also have the exact opposite situation to what you described: a root user running with only normal user permissions.
curious_4207@reddit
I think we're at the point where
run0is a legitimate option, not just an experiment. The tighter integration with systemd and the cleaner privilege escalation model are nice advantages.That said, I wouldn't remove
sudojust because you can. It's still the default on a huge number of systems, most documentation assumes it exists, and plenty of scripts and muscle memory depend on it. For me, the question isn't "run0 or sudo?" so much as "is there a compelling reason to get rid of a tool that's already working?" If you're on a systemd-heavy distro and like the workflow, userun0, but I'd probably keepsudoinstalled for compatibility.backyard_tractorbeam@reddit
run0 seems like a big improvement. Probably a pipe dream but why can't sudo just be reimplemented using run0's method? Would be a lot smoother for interactive use.
vivAnicc@reddit
Its your system, do what you want.
But if you want your scripts to be as generic as possible you should probably use sudo as it is what most people use. You could check if sudo is installed and choose accordingly in every script, if you think its worth the effort
SpeedDaemon1969@reddit
Why do people keep talking about scripts? What script in particular is this an issue for?
Vittulima@reddit
OP brought it up
ChrisTX4@reddit
On systems with systemd >= 256, run0 will be always available and it relies on polkit, which you'd have configured anyway, and which will add the wheel/sudo group as admins by default. Alas, other than the systemd >= 256 (release date: June 11, 2024) restriction, there's no issue. It will be present and working on practically any current Linux distro.
user9ec19@reddit
Does not work on my debian Server, but does work an my Silverblue workstation.
nply@reddit
IMO using sudo in scripts is a bad practice anyway. Better to not add a hard dependency like that and let the user choose if they want to run the script as root or using whatever privilege elevation mechanism they want.
za72@reddit
you got the right idea, a little help library you could write to source in multiple scripts
ComprehensiveHawk5@reddit
I gave run0 a serious try for a few weeks, but there was too many small issues that I didn't like. For some reason it bugged up vim is the one I most remember.
montdidier@reddit
Neither. I use doas.
ipsirc@reddit
doas
Ok-Cook-9039@reddit
sudo. if it ain't broke don't fix it.
SpeedDaemon1969@reddit
I hate tribal either/or comparisons. And frankly, su has worked for me for 30+ years, so I don't need a gimmick.
pastelfemby@reddit
I just use run0 these days, for many uses just even having it as an alias for sudo gets by. Though --empower is also very useful in many cases as well, mentally abbreviated in an alias for me as 'sume'
Patient_Sink@reddit
You could probably do it as a function in your shell instead of an alias, with a case for su doing something special
untemi0@reddit
doas with doas-sudo-shim and doasedit-alternative for some qol
nply@reddit
IMO using either in scripts is a bad practice. Better to not add a hard dependency (and forced interactivity in the case of sudo) like that at all and let the user choose if they want to run the script as root or using whatever privilege elevation mechanism they want.
bingNbong96@reddit
Not really a great idea, it will make the script a lot more brittle (and potentially dangerous).
The first thing that comes to mind is if the whole script runs as root it will make a mess with every file it touches, permissions wise. Also, environment variables will be all messed up ($HOME will be /root for example).
You should only run programs as root when they absolutely need to, this is just asking for trouble.
transconductor@reddit
That would make the script all or nothing in terms of permissions, right?
Depends on the script imo. If it's something the user always runs manually (install scripts for example), running as root as little as possible (and therefore using sudo where necessary) seems preferable to me. If it's something that might be run automatically (backup scripts for example), I'd agree that sudo is a bad practice.
Literallyapig@reddit
i think depending on your script, you could have a variable set at the top that defines the elevation command to run (it could default to sudo). this way, people who use doas, run0 or whatever else can just modify this envvar to the command they use. this would allow the script to only run as root if needed, plus also give users the option to use something other than sudo.
ptico@reddit
doas
BallingAndDrinking@reddit
While the discussion is about sudo or run0, I prefer doas too.
Running both some Linux and FreeBSD, it's available, could even throw more unixes and still be fine.
And doas is pretty simple to properly set too, it's really nice.
gesis@reddit
Right there with you.
I have no problems with configuring sudo, but doas is much clearer. Honestly, I only use elevated permissions for system updates though, for everything else, I just set access permissions appropriately.
wowsomuchempty@reddit
I had a fellow sysadmin (Jr) that ran everything as root. Shot of him, thank god.
abu-aljoj04@reddit
I also use run0. I like that it gives output of the command in a different color. It lets me know visually that I am running a privileged command.
sudogaeshi@reddit
cool, TIL I have run0 up and running!
I'll probably stick with sudo though. I don't think it's a big enough issue to change muscle memory for me
RudahXimenes@reddit
sudo uses privilege escalation to work. That enhances the surface area to attacks. Is not a big issue, tho, because sudo is very well maintained, but still a wider surface area than not using sudo.
run0, otherwise, does not escalate privileges. It uses systemd internal components to run as root. It's kinda different from what sudo does, and it does not has the same issue of privilege escalation.
About muscle memory:
alias sudo=run0solves the issueAnyway, it's just my opinion. You don't need to follow if you don't want to. As I said, sudo is fine as well
sudogaeshi@reddit
I guess I can look into it. I understand what sudo does, but....though I use systemd, that's kind of when my understanding of linux fundamentals started to go south (hey, I'm old and don't do this professionally!)
tajetaje@reddit
Basically with sudo you are executing code as the root user, with run0 you are executing code as your user, but with root permissions. It’s a subtle difference but has security and observability implications that are important. It also fits more in line with the privilege and process hierarchy under systemd (i.e. slices and whatnot)
BitterCelt@reddit
Does this mean I can
run0 nvimand not lose my config setup without having to resort tosudoedit?tajetaje@reddit
Actually run0 strips even more env variables than sudo so not really no
BitterCelt@reddit
Lmao ah well. This thread is this my first encounter with
run0so I'll do some reading and experimenting later.farnoy@reddit
Is that right?
$ run0 touch FILE && stat -c %U FILEshows root as the owner of the file.$ run0 whoamialso returns root. Your description makes it sound like it's still my user account, but with CAP_SYS_ADMIN. Doesn't seem to be the case.tajetaje@reddit
You are UID/GID 0, but still acting as your user from a system perspective if I understand it correctly. There’s a really good blog post from systemd about it though
sudogaeshi@reddit
yeah, to understand I'll really have to dig into the details
teleprint-me@reddit
wasnt enough compared to $ as a visual indicator? Dont get me wrong, Im a sucker for color, but its not like it wasnt possible already. I like the concept of run0, but not the application of it, but thats just my subjective preference.
transconductor@reddit
You don't get the
#when running single commands with sudo as you never see a privileged prompt.teleprint-me@reddit
su -iandsudois temporary privelage escalation, so there would naturally be no indicator of being root while running that process other than checking the uid. but if you appended sudo, you should understand that you are root for that command.nullptr777@reddit
Wow, just tried this and I don't think I could hate it anymore. It looks like shit with my terminal colorscheme, and it overrides whatever colors the command itself would've printed, causing a loss of information.
I'm not a big systemd hater, but this kind of shit is why it gets criticism.
fearless-fossa@reddit
You can alias it to not changing the color, but yeah, it's a dumb default.
tajetaje@reddit
Yeah I feel like distros should disable that by default
s_elhana@reddit
Neither. doas
RudahXimenes@reddit
I've been using run0 for everything. I've even aliased sudo as run0 at my rc file
Now run0 keep your authentication for a while, don't needing to retype your password every time you summon the command. It behaves a lot with sudo, but I trust it more because there is no privilege escalation
funbike@reddit
You can do that with sudo. It's a single line in the config.
RudahXimenes@reddit
I know. I commented that because it was a criticism about run0 while ago. However it does not happens anymore.
My main reason to prefer run0 is that sudo has privilege escalation and run0 don't.
funbike@reddit
I'd argue that run0's password caching makes run0 far worse for security than sudo. Sudo's password caching is per terminal session, whereas run0 is system global and people are tempted to set password caching globally for all polkit use-cases.
If I have two scripts running in 2 terminals, and I type in the password to give one of the scripts access, then 2nd script will also get access (during the password cache timeout).
At least that's how I understand it.
RudahXimenes@reddit
I just tested here. I opened 2 terminal windows. On the first I typed
run0 echo 'Test run0 cacheing'and in the second I typedrun0 pacman -SyuAfter pressing enter in the first window, it asked me my password and then showed the message. Then I pressed up and re-entered the same command, showing me the message again but not asking for any password whatsoever.
Immeaditely changed to the second window and pressed enter in the pacman command. It DOES asked me the password again.
With this infamous test I made, showed me that it was process dependent.
Maybe you can test it yourself and tell me your results.
Here is my
run0 -Vsystemd 260 (260.1-2-arch) +PAM +AUDIT -SELINUX +APPARMOR -IMA +IPE +SMACK +SECCOMP +GCRYPT +GNUTLS +OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 +KMOD +LIBCRYPTSETUP +LIBCRYPTSETUP_PLUGINS +LIBFDISK +PCRE2 +PWQUALITY +P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +BPF_FRAMEWORK +BTF +XKBCOMMON +UTMP +LIBARCHIVE
funbike@reddit
That's a relief. I'll check it tomorrow.
RudahXimenes@reddit
Well, I never changed any config. I remember that in the past run0 required me to enter my password everytime I summoned it. However after some update it kept my password for a few seconds. I implied that it was intended by the devs.
I never tested this caching issue you're talking about and gonna try it. Hope it's not globally as you pointed.
funbike@reddit
You didn't know when it was activated, and they opened up your attack surface without notifying you.
I'm surprised more people aren't talking about this. It's a huge security hole. Giving script A root access will give script B access without you knowing it. So bad.
RudahXimenes@reddit
Agree with you, but it does not like it
Karol-A@reddit
I think it's even a default for many distros, that's how it works for me on Kubuntu and I'm too scared to mess with sudo config
bullwinkle8088@reddit
If you feel secure doing so sudo has the I authenticate option which disables it prompting for a password.
That should obviously be used with care, with at a minimum 2FA and a timed, automatic logout for inactivity.
RudahXimenes@reddit
You totally missed the point.
sudo already keep your authentication for a while. It is the default behavior. However it locks you down after a while.
Just like run0 now.
bullwinkle8088@reddit
You mean the timeout value?
That is not universal across distros or environments. It’s not even been universal across distro releases. That is just a setting in sudoers as well.
RudahXimenes@reddit
Probably it's the timeout value. Most of distros I installed has the timeout set and I never changed it.
gegentan@reddit
Sudo. Otherwise I have to reach for the 0.
mx2301@reddit
Why not doas?
ImBackAgainYO@reddit
why not zoidberg?
whosdr@reddit
I can only imagine a
zoidbergimplementation ofsudo: picks a random user account to execute as. (That is, usually gets it wrong)ImBackAgainYO@reddit
haha, maybe I should make that
whosdr@reddit
Fork and do it.
Freedom freedom freedom oi!
maxwelldoug@reddit
Polkit (with aliases/wrappers for sudo to resolve my muscle memory of sudo do thing)
StephaneiAarhus@reddit
I use doas instead.
edparadox@reddit
After systemd's stance regarding the "birthday" field being added for age verification laws, I got back to thinking maybe it's actually a bad thing that systemd does everything.
10F1@reddit
It's literally a field in a file, 0 way to enforce it.
RoxyMusicVEVO@reddit
I've aliased run0 to pls and it's been working just fine. And now I have to type 25% less.
HieladoTM@reddit
s-u-d-or-u-n-0Hmmm no?
RudahXimenes@reddit
He aliased to pls.
He runs commands like:
pls pacman -SyuHieladoTM@reddit
It would be more funny something like
b*tchordoitFor example:
b*tch dnf install firefox,doit dnf install firefox!Infiniti_151@reddit
I prefer sudo and pkexec.
RudahXimenes@reddit
run0 is essencially pkexec
daemonpenguin@reddit
No, it really is not.
RudahXimenes@reddit
You're right. I edited my comment.
teleprint-me@reddit
So then why do we need run0 if its synonymous with pkexec?
RudahXimenes@reddit
There is some caveats... AFAIK pkexec is somehow limited in some contexts, such as CLI. run0 behaves much more like sudo
I don't know exactly why. I did read it a long time ago and don't remember exactly
ADVallespir@reddit
Why?
BaconCatBug@reddit
I use sudo to run run0
Pitiful-Welcome-399@reddit
doas❤️🩹
KenFromBarbie@reddit
Ah, why is this answer so low in the comments?
Daktyl198@reddit
Sudo-rs, personally
trenixjetix@reddit
i've heard more of doas because it doesnt depend on systemd
FriendlyProblem1234@reddit
Is run0 vulnerable to malicious aliases in
~/.bashrclike sudo, su, doas, and company, that make escalate to root trivial? Otherwise I would stick to just logging in as root on a different tty.But honestly, who cares... Desktops are effectively single user systems. The only user, me, has full access to the system. It can read, modify and delete every document, it can access every device such as microphone or camera, it has full access to network, it can locally install and run applications... The only thing it cannot do is to access other users' documents, but there are no other users, so it is irrelevant.
On a desktop I am not concerned about user separations, instead I very much care about *application* separation.
fearless-fossa@reddit
I like the concept of run0. In practice it's just more effort than sudo and offers less configuration options.
AlphaKaninchen@reddit
I prefer run0 because i can run it as an regular user, and then confirm the polkit dialog as a wheel user, therefore I never need to be logged in as the wheel user, I tried removing sudo completely but that broke my fedora install a little bit...
DFS_0019287@reddit
I use
sudo, but I have it aliased asroot. So I go:root cmd args...I rarely (almost never)
sudoto a non-rootuser, so myrootalias is what I almost always use.I guess my alias would make changing to
run0easy, but I don't really have a compelling reason to do so.supremely-weird@reddit
Sudo, maybe even sudo-rs aliased as 'sudo'
Negative_Settings@reddit
After reading into it a little more I think it's a cool idea for reducing attack surface I'm sure some day if it does become the norm most distros will just alias sudo to run0 lol
daemonpenguin@reddit
I use FreeBSD and I run doas on most of my machines so I don't need to mentally switch gears when logging into different servers.
HieladoTM@reddit
I prefer
sudo, simply because it's more flexible for the things I need to do on my computer. Another thing (but this is purely a personal preference) is that I don't like having to type words and numbers together; it's silly and can be fixed with an alias, but I don't like typingrun0.pleasant-peasant859@reddit
i just used it for the first time. i think i'm going to read into it and start using this instead for my scripts as well.