ssm@lemmy.sdf.org
on 03 Jul 2024 17:31
nextcollapse
No, it’ll just be yet another pile of bloat that’ll separate IBM distros and their followers (rhel, fedora, centos, debian, arch) from the rest (alpine, void, gentoo, devuan, *BSD).
GolfNovemberUniform@lemmy.ml
on 03 Jul 2024 17:38
nextcollapse
Wait Arch and Debian are owned by IBM? It sounds like one insane piece of conspiracy tbh.
Arch ships redhat userland (systemd) and doesn’t support alternative userlands; you have to go to artix for that.
boredsquirrel@slrpnk.net
on 03 Jul 2024 17:47
collapse
And neither Arch, nor Ubuntu, nor Debian, nor OpenSUSE, nor any other distro using systemd belongs to IBM.
systemd has nothing to do with any corporation doing bad stuff to “our Linux”.
It is just newer software, doing more things more easily.
Sure, the centralization is pretty damn bad. But for example replacing sudo is needed.
GolfNovemberUniform@lemmy.ml
on 03 Jul 2024 17:51
nextcollapse
Btw can RH as the biggest contributor to systemd make it paid like it did with RHEL? Then it’s going to be the death of the free and independent Linux desktop for quite a while.
Aqler@discuss.online
on 03 Jul 2024 18:00
nextcollapse
Don’t spread lies, misinformation and/or FUD.
Btw can RH as the biggest contributor to systemd make it paid like it did with RHEL?
It’s not. They’ve only made it harder for other parties to freely benefit from RHEL’s hard work at the expense of RHEL.
GolfNovemberUniform@lemmy.ml
on 03 Jul 2024 18:19
collapse
Don’t spread lies, misinformation and/or FUD.
Uhm what? I asked a question bruh.
They’ve only made it harder for other parties to freely benefit from RHEL’s hard work
True but they still can find something to hurt everyone. Not like I think it will happen but it is a problem with centralization and a company being behind a big and important product.
Aqler@discuss.online
on 03 Jul 2024 18:30
collapse
Uhm what? I asked a question bruh.
The bold parts include a false claim; i.e. Red Hat made RHEL paid.. So it’s perfectly possible to include a lie, piece of misinformation and/or straight up FUD within a question.
True but they still can find something to hurt everyone. Not like I think it will happen but it is a problem with centralization and a company being behind a big and important product.
I agree with you that Red Hat is indeed way too powerful in this realm. Hence, there will inevitably always be the fear that they might (somehow) misuse their power. So far, they’ve been mostly benevolent and I hope it will stay that way. There’s no fault at being cautious, but this should never lead us towards toxic behavior.
EDIT: Why the downvotes?
GolfNovemberUniform@lemmy.ml
on 03 Jul 2024 18:38
collapse
The bold parts include a false claim; i.e. Red Hat made RHEL paid..
Isn’t it? And for distro devs access to the source code is the only thing that matters. I am quite sure it is paid.
There’s no fault at being cautious, but this should never lead us towards toxic behavior.
I agree but I think you are the toxic one here. You boldly accuse a kinda new Linux user that asks a question in sharing misinformation and being toxic. I kinda get the first part but the second? You either don’t know what toxicity is or you’re just being toxic.
Aqler@discuss.online
on 03 Jul 2024 19:17
collapse
Isn’t it?
No-cost RHEL is accessible for individuals or small teams up to 16 devices. RHEL is paid for enterprises and businesses because of its support; which also includes (exclusive) articles and documentation.
You made it seem as if you were regurgitating the common line of misinformation when last year Red Hat changed how access to RHEL’s source code worked.
That regurgitated statement is misinformation. Besides that event, which actually didn’t make RHEL paid, I’m unaware of Red Hat retroactively changing a formerly free service to cost money instead.
And for distro devs access to the source code is the only thing that matters.
Do you mean the people working on Oracle Linux, AlmaLinux OS and/or Rocky Linux? Or did you actually primarily imply others? If so, could you elaborate?
but I think you are the toxic one here.
😅. Sorry, this is just not very productive. But, I will try to be more careful with the language I use when communicating with you 😉.
You boldly accuse a kinda new Linux user that asks a question in sharing misinformation
If, with your earlier statement, you meant the whole RHEL source code fiasco from last year, then that’s plain misinformation. And if you share that, then that’s sharing misinformation.
I prefer open conversation in which we can communicate directly. If you’re sensitive to that, then I will abstain from doing so when I’m interacting with you.
and being toxic.
At worst, I only implied it. At best, it’s a general advice directed towards anyone that happens to read it. To be clear, I didn’t intend to attack you. So no need to be offended. Nor should you take it personally.
Finally, as this comment of yours clearly shows, you’re at least somewhat susceptible to misunderstand the writing of others. Ain’t we all to some degree? Though…, (perhaps) some more than others. Regardless, likewise, without trying to offend you or whatsoever, I would like to propose the idea that you might have jumped to conclusions that you didn’t have to necessarily.
ssm@lemmy.sdf.org
on 03 Jul 2024 18:10
nextcollapse
If IBM makes redhat do something that greedy and stupid (it’d be more likely to happen with a distribution like fedora or centos than userland components), we have plenty of existing infrastructure to fall back on.
GolfNovemberUniform@lemmy.ml
on 03 Jul 2024 18:16
collapse
(it’d be more likely to happen with a distribution like fedora or centos than userland components
I mean, if they make an actual workstation distro and kill systemd’s real FOSS nature, everyone else will have to spend some time rebuilding their distros with other init systems. That’ll be quite a sabotage.
maniii@lemmy.world
on 03 Jul 2024 19:38
nextcollapse
You are not wrong. IBM management paralleled in the same cash-grab and exit C-suite functions that has consumed Redhat. That is why the merger happened.
Soon, Purple Hat should be charging for systemd and hopefully other corpos and organizations will move back to sanity.
Chewy7324@discuss.tchncs.de
on 03 Jul 2024 20:46
collapse
Soon, Purple Hat should be charging for systemd and hopefully other corpos and organizations will move back to sanity.
Unless otherwise noted, the systemd project sources are licensed under the terms and conditions of LGPL-2.1-or-later (GNU Lesser General Public License v2.1 or later).
New sources that cannot be distributed under LGPL-2.1-or-later will no longer be accepted for inclusion in the systemd project to maintain license uniformity.
I can understand critism of systemd for its tools only working with itself and not with any other Unix tools. But it’s absolutely a conspiracy theory to think they’d want to charge for systemd. Though I do agree that if someone was charging for systemd (which they can’t because its open source), open source alternatives would pop up.
boredsquirrel@slrpnk.net
on 03 Jul 2024 21:10
nextcollapse
RedHat is not restricting access to any upstream project. They package things in extremely stable form, which means they need to manage like all the software themselves and do tons of backports, as normally software just releases new versions.
They restrict access to these packages.
So yes, their 5 years old systemd with backported security fixes may be restricted. But not the normal systemd you can install anywhere.
gh0stcassette@lemmy.blahaj.zone
on 04 Jul 2024 16:56
collapse
No, it’s licensed under the LGPL, which means source code can be freely distributed and distros would continue to package it for free no matter how hard Redhat tried to paywall it.
ssm@lemmy.sdf.org
on 03 Jul 2024 17:56
nextcollapse
And neither Arch, nor Ubuntu, nor Debian, nor OpenSUSE, nor any other distro using systemd belongs to IBM.
Where did I say they belong to IBM?
Sure, the centralization is pretty damn bad. But for example replacing sudo is needed.
We already have doas, which is such a simple codebase I’d have a hard time imagining it contains a bug that leads to setuid being a problem. run0’s codebase size on the other hand…
bionicjoey@lemmy.ca
on 03 Jul 2024 18:59
nextcollapse
But for example replacing sudo is needed.
Seriously asking: what’s wrong with Sudo? And aren’t there already loads of alternatives?
maniii@lemmy.world
on 03 Jul 2024 19:35
nextcollapse
systemd nightmare needs to end. Too many broken garbage from malicious actors within the opensource community.
Just as an experiment, get every distro to have at least 2 or 3 SysVInit / runit / rc.init alternatives, and you will see a MASS Migration back to SysVInit. Bash/shell script init functions were really dead simple and almost unbreakable/hackerproof.
Systemd really needs to be thrown in the garbage dumps of history so we can finally have a UNIX-like boot back.
Blisterexe@lemmy.zip
on 03 Jul 2024 19:45
nextcollapse
If systemd is as bad as you claim why did nearly every distro switch to it?
Corpo sabotage of opensource. So many community projects are under the thumb of corpo insiders. It was a “cash-grab” a way to shoehorn and takeover an essential but mostly unchanged and stable Init system. And they shimmed that into everything they could ram it into with no options or alternatives.
boredsquirrel@slrpnk.net
on 03 Jul 2024 21:08
nextcollapse
Why would corporations prefer it?
SaltySalamander@fedia.io
on 03 Jul 2024 22:32
nextcollapse
You should probably take the tin-foil hat off once in a while to let that noggin of yours breathe a little.
What exactly did companies gain from making Linux distros switch over to systemd?
If anything, the switch ment a loss of productivity as their staff needed to relearn stuff, not to mention loss of technical knowledge as there would be others who simply would not accept the change and leave the company when the change happened.
This means increased costs, either due to retraining, or due to needing to hire new staff which is expensive.
Meanwhile, I can’t see anything that would mean that companies would earn or even save enough money to make it worth the effort of making distros implement systemd.
Ok so doing it for direct gain seems to be out, but you mention “corpo sabotage of opensource”, I can’t really see that either, a developer won’t move a successful Linux project to Windows, AIX, Solaris, Darwin or HP-UX just because of a move to systemd.
So even indirect gain seems to be out, so “corpo sabotage” doesn’t really seem plausible.
But, I may be wrong, please, tell us how exactly a move to systemd has benefited companies enough that it would make the effort and expense to make a distro move to sytemd, let alone a majority of distros, worth it.
But, I may be wrong, please, tell us how exactly a move to systemd has benefited companies enough that it would make the effort and expense to make a distro move to sytemd, let alone a majority of distros, worth it.
you’re putting to much thought in something that even the guy who you’re asking didn’t
exu@feditown.com
on 03 Jul 2024 20:03
nextcollapse
As someone who writes bash scripts, fuck no, this is a terrible language and it shouldn’t be used for anything more complex than sticking two programs together.
Also, parallelism goes right out of the window.
Maybe you’d convince me with a real programming language.
SuperIce@lemmy.world
on 03 Jul 2024 21:14
nextcollapse
That just made me imagine a Rust rewrite of systemd
There is (was?) a group writing a whole Linux-esque OS in Rust: github.com/nuta/kerla
db0@lemmy.dbzer0.com
on 04 Jul 2024 06:36
collapse
Any time I see a grognard seriously suggest going back to bash for anything exceeding 10 lines of code it makes me very happy none of them are in control.
that’s some high ammount of copium from someone that never made a distro
boredsquirrel@slrpnk.net
on 03 Jul 2024 21:12
collapse
I suppose doas is a pretty great alternative.
Smaller code is often good, but not always.
MonkderDritte@feddit.de
on 03 Jul 2024 19:04
nextcollapse
But for example replacing sudo is needed.
There’s plenty of 100-loc tools for that already. And doas, who has most of sudo’s server-features, is not much bigger.
And they all work even without systemd or services.
deadbeef79000@lemmy.nz
on 03 Jul 2024 20:59
collapse
Eeeh, if anything, systemd is Microsoft’s contribution.
/s sort of
Aqler@discuss.online
on 03 Jul 2024 17:54
collapse
For clarity, because the obnoxious ones out there didn’t get it, this refers to how Arch, Debian, Fedora and most other distros just default to systemd and hence can (and probably will) make use of run0. While, on the other hand, distros like Alpine, Artix, Devuan, Void and others (including *BSD-systems) will not. For distros with no defaults (e.g. Gentoo), the user gets to decide.
LainTrain@lemmy.dbzer0.com
on 03 Jul 2024 17:46
nextcollapse
If you make users sign in too much, they will just make their passwords short and easy to remember, even 24hrs is too much and people bitch about it all the time, especially since we have password managers enforced, meaning every time they need to Auth they need to Auth into their system, Auth into their password manager, copy the password, auth into their phone, look at the 2FA code and type that in.
Doing this every day just to open email is understandably fucking enraging even to me as a security “”“engineer”“”/analyst/${bullshitblueteamemailreaderjob}
Press it harder and they will use simple passwords that will inevitably be passed through to something external (e.g. cockpit which even I can bruteforce) or reused somewhere at some point, and then someone just has to get lucky once and run whatever run0 sudo su <reverse shell bs here> to bypass all protections.
Revan343@lemmy.ca
on 04 Jul 2024 02:19
nextcollapse
or reused somewhere everywhere at some point constantly
MonkderDritte@feddit.de
on 03 Jul 2024 19:07
nextcollapse
Meaning, run0 is overengineered too?
TMP_NKcYUEoM7kXg4qYe@lemmy.world
on 04 Jul 2024 06:12
nextcollapse
imo it’s kinda like bash’s bloatness. Sure, I’d use a less bloated shell but I need bash as a bash interpreter regardless, so using a smaller shell would actually be more bloat. In a similar way you already have systemd, so you don’t really gain any more bloat by having this alias for systemd-run or how it’s called.
MonkderDritte@feddit.de
on 04 Jul 2024 13:48
collapse
No, like, alternatives to systemd-stuff often do the same job in 1/3 or 1/10 the code.
TMP_NKcYUEoM7kXg4qYe@lemmy.world
on 04 Jul 2024 05:54
collapse
run0 is just an alias for a part of systemd, so installing doas too would be useless bloat. Another thing to note is that doas is just smaller sudo, you still wouldn’t use 99 % of its features.
edit: also from my totally surface level understanding both sudo and doas “elevate your privileges” which is supposedly unnecessary attack surface. run0 does it in a better way which I do not understand.
Laser@feddit.org
on 04 Jul 2024 09:42
nextcollapse
also from my totally surface level understanding both sudo and doas “elevate your privileges” which is supposedly unnecessary attack surface. run0 does it in a better way which I do not understand.
sudo and doasare setuid binaries, a special privileged bit to tell the kernel that this binary is not run as the user starting it, but as the owner. A lot of care has to be incorporated into these to make sure you don’t escalate your privileges as the default interface is very limited, being a single bit.
Another issue with this approach is that since you’re running this from your shell, the process will by default inherit all environment variables, which can be convenient, but also annoying (since a privileged process might write into your $HOME) or upright dangerous.
run0doesn’t use that mechanism. systemd is, being a service manager at its core, something launching binaries in specialized environments, e.g. it will start an nginx process under the nginx user with a private tmp, protecting the system from writes by that service, maybe restrict it to a given address family etc. So the infrastructure to launch processes – even for users via systemd-run– is already there. run0 just goes one step further and implements an interface to request to start elevated (or rather with permissions different from their own) processes from a user’s shell.
Classic solutions do it like this:
user starts binary with setuid (let’s say sudo) that runs with root (because that’s the owner of the binary) privileges in their shell. Since this is a child process of their shell, it inherits all environment variables by default.
sudochecks /etc/sudoers if that user is authorized to perform the requested action and either denies the request, performs it or asks for authentication.
a new process is spawned from it, again inheriting the environment variables that were not cleaned, as you can’t get rid of variables by forking (this is often an issue if you have services that have their secrets configured via environment variables)
With run0:
user starts run0 binary as a user process. This process inherits the environment variables.
run0 forwards the user’s request via interface to the running systemd process (pid 1 I guess). That process however does not inherit any variables by default, since it was started outside the user’s shell.
systemd checks if the user who started the run0 binary is allowed to perform the requested operation and again, either denies the request, performs it or asks for authentication.
a new process is spawned from it, but it will only receive the environment variables that were explicitly requested as there’s no inheritance.
At least that’s my understanding, I haven’t looked too much into it or used it yet.
the pid1 part is wrong, only the systemd-init run in pid1, in it’s own process, own binary etc, it’s sole purpose is being an init system, after that it start the rest of the system, including the others systemd binaries
the rest is perfect thanks!, in the lennart he made a comparation with ssh were you “forward the commad to run as root”, i think it’s a good analogy
. run0 does it in a better way which I do not understand.
it does that in a “ssh like” that i read in the blog, they foward your commands, they don’t elevate your user, they also use polkit for security intead of sudoers
TMP_NKcYUEoM7kXg4qYe@lemmy.world
on 04 Jul 2024 06:05
collapse
The original problem was to automagically prompt the user for password, if he tried to run some systemd executable without the wheel privileges. At some point they decided to reuse the code for [a command that allows you to run stuff as root] replacement because sudo is too bloated and vulnerable.
Kyatto@leminal.space
on 03 Jul 2024 19:32
nextcollapse
As it is running sudo with a long process is annoying missing and having to reenter my password or missing and the process timing out if I go afk to wait, I can’t imagine having to type my password every few moments when I run an upgrade. Surely this is not the pitch. This is already looking dead in the water if so, and god help me if I have to remember to type run0.
caseyweederman@lemmy.ca
on 03 Jul 2024 23:01
collapse
No no no
It’ll be systemctl --user enable --now systemd-run0d
Kyatto@leminal.space
on 04 Jul 2024 00:32
collapse
I’m dead
kenkenken@sh.itjust.works
on 03 Jul 2024 19:55
nextcollapse
I will use it. I don’t care what others think. People can use su, sudo, doas, run0 by their choice, and I don’t see why we need a common opinion about it.
circuitfarmer@lemmy.sdf.org
on 04 Jul 2024 02:11
collapse
This. One thing Linux is about is personal freedom.
exu@feditown.com
on 03 Jul 2024 20:01
nextcollapse
I might try run0 for fun, but I don’t think it’ll replace sudo any time soon.
The biggest issue I see is run0 purposely not copying any environment variables except for TERM.
You’d have to specify which editor to use, the current directory, stuff like PATH and HOME every time you run a command.
I'm not a fan of the idea at all, but come on, it can't really be that bad. There's got to be somewhere you can tell it what environment variables to use. Probably something like run0 systemd-edit /usr/system/systemd/systemrun/run0-environment --system-default=system
Penguincoder@beehaw.org
on 03 Jul 2024 23:07
nextcollapse
Maybe, but now I still need to remember the alias or distribute it to any machine I’m working on.
Not that difficult if you have everything managed with Ansible or similar anyways, but lots of people likely don’t have that setup.
The beauty of Linux at home, you get to choose what works best for you.
TMP_NKcYUEoM7kXg4qYe@lemmy.world
on 04 Jul 2024 05:50
collapse
Yeah I mean at that point it’s redundant because you might as well type su -c “some command here”. On the other hand having such alias does no harm if you’re already using systemd.
ada@lemmy.blahaj.zone
on 03 Jul 2024 23:43
nextcollapse
At the moment, fish doesn’t know what to do with run0. When that changes, I’ll start using it :)
Titou@sh.itjust.works
on 04 Jul 2024 05:37
nextcollapse
I’ll stick with doas
null@lemmy.sdf.org
on 04 Jul 2024 05:49
nextcollapse
doass
PoorPocketsMcNewHold@lemmy.ml
on 04 Jul 2024 08:47
collapse
Speaking of doas, is there any advantage of using it when… sudo is still available to be used? I agree that most of the stuff we require to use doesn’t need all the options sudo as, but if it is for the sake of security, maintenance, and stability… is there any reason to use doas ON TOP of the already setup sudo or su? In the past, I even tried to just apply a simple alias to replace sudo with doas, but numerous scripts and programs when trying to request explicit super-user permissions, just didn’t know what to do with doas as expected, so this ain’t it.
Titou@sh.itjust.works
on 04 Jul 2024 09:08
nextcollapse
I agree that most of the stuff we require to use doesn’t need all the options sudo as
Main reason of using doas
but numerous scripts and programs when trying to request explicit super-user permissions, just didn’t know what to do with doas as expected
I’ve only found one software like that and it’s tipi, and it’s kinda dumb for a software to require such a easily replacable software. Also how openbsd users are supposed to do ? Having both doas and sudo on their machine which is unnecessary bloat ?
PoorPocketsMcNewHold@lemmy.ml
on 17 Jul 2024 14:34
collapse
Sure do confirm that hard-coded sudo requirements are kinda dumb. But this proove systemd point. BSD mainly use doas. Linux mainly use sudo. Why not have an universal method for true cross-platform compatibility ?
(Yes, I know plenty prefer or explicitly are against the usage of systemd suite of software, was pointing out systemd main reason of planning to propose an another standard, regardless if it will be popular or not)
Speaking of doas, is there any advantage of using it when… sudo is still available to be used?
I like that its configuration file is very very simple.
PoorPocketsMcNewHold@lemmy.ml
on 17 Jul 2024 14:31
collapse
When was the last time you had to edit sudo configuration file ? Same goes for doas. It’s has nothing going for, for the majority of desktop Linux users (from what I got as an answer)
A month ago or so to be able to use zramen without root password.
electricprism@lemmy.ml
on 04 Jul 2024 08:43
nextcollapse
Sometimes I really hate the utility names people come up with.
I would love to see chatgpt rename all the core utils in a way that summarizes their function.
toastal@lemmy.ml
on 04 Jul 2024 11:51
nextcollapse
The name does do what it says & in just 4 char
sping@lemmy.sdf.org
on 04 Jul 2024 13:33
nextcollapse
I feel like this is well named (run as user 0) so then I’m wondering what else you dislike and what you think would be improvements?
electricprism@lemmy.ml
on 04 Jul 2024 17:47
collapse
My complaint was mostly targeting the big picture of everything living in /bin/
I inferred the ‘user 0’ thing to their credit like you, it just still felt really strange as numerals are kind of a no no when programming – you can’t begin variable and other names with them and I guess having them as a suffix feels strange too as it’s not common practice.
It will definitely be the only utility I recall that uses a numeral.
To me the whole numeral systems are archaic, User ID numbers don’t line up when transferring data from hard drives from another machine eg 1000-1005.
The numeral permission system is archaic and requires explicit knowledge to know the difference between a 7 6 and 4. In GUI Immutability is separate when it should be more integrated as a file control. The octal permissions are from another decade and modern platforms have permissions on whether a executible can access the internet, access input devices like camera or microphone, or sensitive data like contacts, pictures, etc…
I think file tagging should be greatly expanded, IDv3 meta data for example was a workaround for the limitations and the core filesystem should have robust enough tagging to make it unnecessary.
I’ll be controversial now – eliminate the . prefix to hide files. Yes I know it had been this way for decades and was grandfathered in as a feature after a bug, that should have been in the filesystem properties like chattr +I and you shouldn’t need .hidden indexes to hide files just like windows and osx litters zip files with MDF or inf or whatever (memory is fuzzy from non use).
Some people say “4 character” limit, that needs to go too – FHS naming structure is confusing and not self evident what it does to people trying to learn who already have IT training. /etc/ having 2 or more bins /bin vs /usr/bin – ‘what does usr mean the new it ponders’ ‘oh it must mean ‘user’ I guess’. – weird stuff like that.
To systemd credit they have no problem being controversial and relentlessly persuing their vision in a practical way, hell I use their stuff hapilly.
I just feel like the run0 thing is a band aid on bigger problems, and AI critique would be very fascinating to make these human interfaces you know… more for us humans :P
If not systemd, maybe the rust people or someone else will be baller enough to try to tackle these funny ackward quirks that have accumulated over the years and straighten it all out.
LemoineFairclough@sh.itjust.works
on 05 Jul 2024 16:48
collapse
It will definitely be the only utility I recall that uses a numeral.
provide about 50%–80% of what you want from an operating system
one expects that if the 50% functionality Unix and C support is satisfactory, they will start to appear everywhere.
Unix and C are the ultimate computer viruses.
users have already been conditioned to accept worse than the right thing.
It’s probably possible to make several programs with “50% functionality” in the time it takes to make one program with 100% functionality. Having more programs that are suitable for a majority of relevant applications is probably better than having one program that is suitable for all relevant applications, since having more programs will probably enable a larger variety of problems to be solved, and people often have to solve many different types of problems in their life.
It run’s an executable as the user with id 0 (root) and it’s called run0.
onlooker@lemmy.ml
on 04 Jul 2024 09:17
nextcollapse
I don’t know, we’ll just have to see. But personally, I am not a fan of tying so many functionalities to systemd.
steeznson@lemmy.world
on 04 Jul 2024 14:37
nextcollapse
I’m going to continue to keep avoiding Poettering software for as long as he continues to act like a jackass. Even his commit messages are dripping with condescension.
Funny. I didn’t know a single thing about the person. But that commit message made me like him more.
Ofc assuming he was just making a light-hearted joke in it.
steeznson@lemmy.world
on 04 Jul 2024 15:18
nextcollapse
Users were complaining that their terminal transparency was being broken by the nspawn container and that the colour for other applications like tmux were being affected by it. For example tmux was appearing in the same navy blue in the terminal emulator instead of its usual green.
Idk he’s just a hot take merchant basically. He has a particular hate-boner for distros that don’t use systemd as the default init system like void and gentoo (usually these are troll tweets as opposed to commit messages though).
Idk he’s just a hot take merchant basically. He has a particular hate-boner for distros that don’t use systemd as the default init system like void and gentoo (usually these are troll tweets as opposed to commit messages though).
shut up, wtf that has todo with the commit, people who don’t use systemd it’s not going to complain about the color of something that they don’t use
steeznson@lemmy.world
on 04 Jul 2024 16:47
nextcollapse
laughterlaughter@lemmy.world
on 05 Jul 2024 14:26
collapse
You’ll have to give another example in order to support your point. Because that commit was funny!
AndrewZabar@lemmy.world
on 04 Jul 2024 14:44
nextcollapse
I’m surprised they would implement having just run0 effectively log you in as root. For the super security conscious constrictions of the command versus sudo, it would seem that the very notion of elevating your privilege beyond the single command to be carried out, would be anathema to the whole goal of this new command. Evidently not, but it’s surprising to me.
you can run a command using run0 it’s only elevating that commads, sometimes it’s needed to login as root, it’s life
laughterlaughter@lemmy.world
on 05 Jul 2024 14:25
collapse
I’m trying to understand what you just wrote. Did you miss a period somewhere?
LeFantome@programming.dev
on 05 Jul 2024 14:50
collapse
They did not miss anything. They just used commas where periods should be.
You can run a command using run0. It’s only elevating that command. Sometimes it’s needed to login as root. It’s life.
The way it is written, semi-colons may be more appropriate but that would be a lot of them.
laughterlaughter@lemmy.world
on 05 Jul 2024 15:17
collapse
You actually pointed out that they did, indeed, do miss a period (the one after “run0.”)
you can run a command using run0 it’s only elevating that commads,
mexicancartel@lemmy.dbzer0.com
on 04 Jul 2024 15:44
nextcollapse
su is the best. I mean, i should be using the admin (root) password for admin things, not the user password of user who is already logged in. And there needs to be a root service already running to make user have root previlages which is dumb imo. Sudo vulnerability could cause previlage escalation but if there is no root process managing this, then it can’t leak the root access. Only kernel security issue(or other root processes) will leak root access if that was the case, which i think is better.
steeznson@lemmy.world
on 04 Jul 2024 17:21
nextcollapse
Completely agree with this take. There are dozens of us!
Cryxtalix@programming.dev
on 05 Jul 2024 16:49
collapse
The permission to do admin things is given by the root user, to your account. So you have to verify your identity by entering your password.
Isn’t that how it is? I though that was analogous to how almost everything worked IRL. Whether withdrawing funds from a bank or engaging government services, you prove your identity as a customer/citizen to get the relevant services. At no point do you login to bank or government computers with full privileges.
mexicancartel@lemmy.dbzer0.com
on 06 Jul 2024 02:44
collapse
If you own your own bank, then i think you login as the one with full previlages. Yes when doing administrator things, you have to use sudo. The problem with root with sudo is, you authenticate as a user, then gain full permission from root, i.e analogous to login in to bank with full previlages.
As a person who need to run sudo command its better to just verify yourself as root user to gain “full access”. I’m not saying about partial previlages. That is i just need a script which is just su -c with environment variables being copied
theshatterstone54@feddit.uk
on 07 Jul 2024 09:47
collapse
I see where you’re coming from, but in enterprise environments, you have admin accounts and root login is disabled for security purposes.
mexicancartel@lemmy.dbzer0.com
on 07 Jul 2024 10:47
collapse
Sure. Sudo is a super useful tool in such places. The problem I have is that it is stuffed into the desktop
gari_9812@lemmy.world
on 06 Jul 2024 12:06
nextcollapse
threaded - newest
No, it’ll just be yet another pile of bloat that’ll separate IBM distros and their followers (rhel, fedora, centos, debian, arch) from the rest (alpine, void, gentoo, devuan, *BSD).
Wait Arch and Debian are owned by IBM? It sounds like one insane piece of conspiracy tbh.
Nah, I’m just referring to IBM’s acquisition of redhat. I’ve been referring to redhat as IBM in kind.
How is RH related to Arch lol? By having GNU core utils?
Arch ships redhat userland (systemd) and doesn’t support alternative userlands; you have to go to artix for that.
And neither Arch, nor Ubuntu, nor Debian, nor OpenSUSE, nor any other distro using systemd belongs to IBM.
systemd has nothing to do with any corporation doing bad stuff to “our Linux”.
It is just newer software, doing more things more easily.
Sure, the centralization is pretty damn bad. But for example replacing sudo is needed.
Btw can RH as the biggest contributor to systemd make it paid like it did with RHEL? Then it’s going to be the death of the free and independent Linux desktop for quite a while.
Don’t spread lies, misinformation and/or FUD.
It’s not. They’ve only made it harder for other parties to freely benefit from RHEL’s hard work at the expense of RHEL.
Uhm what? I asked a question bruh.
True but they still can find something to hurt everyone. Not like I think it will happen but it is a problem with centralization and a company being behind a big and important product.
The bold parts include a false claim; i.e. Red Hat made RHEL paid.. So it’s perfectly possible to include a lie, piece of misinformation and/or straight up FUD within a question.
I agree with you that Red Hat is indeed way too powerful in this realm. Hence, there will inevitably always be the fear that they might (somehow) misuse their power. So far, they’ve been mostly benevolent and I hope it will stay that way. There’s no fault at being cautious, but this should never lead us towards toxic behavior.
EDIT: Why the downvotes?
Isn’t it? And for distro devs access to the source code is the only thing that matters. I am quite sure it is paid.
I agree but I think you are the toxic one here. You boldly accuse a kinda new Linux user that asks a question in sharing misinformation and being toxic. I kinda get the first part but the second? You either don’t know what toxicity is or you’re just being toxic.
No-cost RHEL is accessible for individuals or small teams up to 16 devices. RHEL is paid for enterprises and businesses because of its support; which also includes (exclusive) articles and documentation.
You made it seem as if you were regurgitating the common line of misinformation when last year Red Hat changed how access to RHEL’s source code worked.
That regurgitated statement is misinformation. Besides that event, which actually didn’t make RHEL paid, I’m unaware of Red Hat retroactively changing a formerly free service to cost money instead.
Do you mean the people working on Oracle Linux, AlmaLinux OS and/or Rocky Linux? Or did you actually primarily imply others? If so, could you elaborate?
😅. Sorry, this is just not very productive. But, I will try to be more careful with the language I use when communicating with you 😉.
If, with your earlier statement, you meant the whole RHEL source code fiasco from last year, then that’s plain misinformation. And if you share that, then that’s sharing misinformation.
I prefer open conversation in which we can communicate directly. If you’re sensitive to that, then I will abstain from doing so when I’m interacting with you.
At worst, I only implied it. At best, it’s a general advice directed towards anyone that happens to read it. To be clear, I didn’t intend to attack you. So no need to be offended. Nor should you take it personally.
Finally, as this comment of yours clearly shows, you’re at least somewhat susceptible to misunderstand the writing of others. Ain’t we all to some degree? Though…, (perhaps) some more than others. Regardless, likewise, without trying to offend you or whatsoever, I would like to propose the idea that you might have jumped to conclusions that you didn’t have to necessarily.If IBM makes redhat do something that greedy and stupid (it’d be more likely to happen with a distribution like fedora or centos than userland components), we have plenty of existing infrastructure to fall back on.
I mean, if they make an actual workstation distro and kill systemd’s real FOSS nature, everyone else will have to spend some time rebuilding their distros with other init systems. That’ll be quite a sabotage.
You are not wrong. IBM management paralleled in the same cash-grab and exit C-suite functions that has consumed Redhat. That is why the merger happened.
Soon, Purple Hat should be charging for systemd and hopefully other corpos and organizations will move back to sanity.
From systemd licenses readme:
I can understand critism of systemd for its tools only working with itself and not with any other Unix tools. But it’s absolutely a conspiracy theory to think they’d want to charge for systemd. Though I do agree that if someone was charging for systemd (which they can’t because its open source), open source alternatives would pop up.
RedHat is not restricting access to any upstream project. They package things in extremely stable form, which means they need to manage like all the software themselves and do tons of backports, as normally software just releases new versions.
They restrict access to these packages.
So yes, their 5 years old systemd with backported security fixes may be restricted. But not the normal systemd you can install anywhere.
No, it’s licensed under the LGPL, which means source code can be freely distributed and distros would continue to package it for free no matter how hard Redhat tried to paywall it.
Where did I say they belong to IBM?
We already have doas, which is such a simple codebase I’d have a hard time imagining it contains a bug that leads to setuid being a problem. run0’s codebase size on the other hand…
Seriously asking: what’s wrong with Sudo? And aren’t there already loads of alternatives?
systemd nightmare needs to end. Too many broken garbage from malicious actors within the opensource community.
Just as an experiment, get every distro to have at least 2 or 3 SysVInit / runit / rc.init alternatives, and you will see a MASS Migration back to SysVInit. Bash/shell script init functions were really dead simple and almost unbreakable/hackerproof.
Systemd really needs to be thrown in the garbage dumps of history so we can finally have a UNIX-like boot back.
If systemd is as bad as you claim why did nearly every distro switch to it?
Corpo sabotage of opensource. So many community projects are under the thumb of corpo insiders. It was a “cash-grab” a way to shoehorn and takeover an essential but mostly unchanged and stable Init system. And they shimmed that into everything they could ram it into with no options or alternatives.
Why would corporations prefer it?
You should probably take the tin-foil hat off once in a while to let that noggin of yours breathe a little.
What exactly did companies gain from making Linux distros switch over to systemd?
If anything, the switch ment a loss of productivity as their staff needed to relearn stuff, not to mention loss of technical knowledge as there would be others who simply would not accept the change and leave the company when the change happened.
This means increased costs, either due to retraining, or due to needing to hire new staff which is expensive.
Meanwhile, I can’t see anything that would mean that companies would earn or even save enough money to make it worth the effort of making distros implement systemd.
Ok so doing it for direct gain seems to be out, but you mention “corpo sabotage of opensource”, I can’t really see that either, a developer won’t move a successful Linux project to Windows, AIX, Solaris, Darwin or HP-UX just because of a move to systemd.
So even indirect gain seems to be out, so “corpo sabotage” doesn’t really seem plausible.
But, I may be wrong, please, tell us how exactly a move to systemd has benefited companies enough that it would make the effort and expense to make a distro move to sytemd, let alone a majority of distros, worth it.
you’re putting to much thought in something that even the guy who you’re asking didn’t
As someone who writes bash scripts, fuck no, this is a terrible language and it shouldn’t be used for anything more complex than sticking two programs together.
Also, parallelism goes right out of the window.
Maybe you’d convince me with a real programming language.
That just made me imagine a Rust rewrite of systemd
There is (was?) a group writing a whole Linux-esque OS in Rust: github.com/nuta/kerla
Any time I see a grognard seriously suggest going back to bash for anything exceeding 10 lines of code it makes me very happy none of them are in control.
that’s some high ammount of copium from someone that never made a distro
I suppose doas is a pretty great alternative.
Smaller code is often good, but not always.
There’s plenty of 100-loc tools for that already. And doas, who has most of sudo’s server-features, is not much bigger.
And they all work even without systemd or services.
Eeeh, if anything, systemd is Microsoft’s contribution.
/s sort of
For clarity,
because the obnoxious ones out there didn’t get it,this refers to how Arch, Debian, Fedora and most other distros just default to systemd and hence can (and probably will) make use ofrun0. While, on the other hand, distros like Alpine, Artix, Devuan, Void and others (including *BSD-systems) will not. For distros with no defaults (e.g. Gentoo), the user gets to decide.If you make users sign in too much, they will just make their passwords short and easy to remember, even 24hrs is too much and people bitch about it all the time, especially since we have password managers enforced, meaning every time they need to Auth they need to Auth into their system, Auth into their password manager, copy the password, auth into their phone, look at the 2FA code and type that in.
Doing this every day just to open email is understandably fucking enraging even to me as a security “”“engineer”“”/analyst/${bullshitblueteamemailreaderjob}
Press it harder and they will use simple passwords that will inevitably be passed through to something external (e.g. cockpit which even I can bruteforce) or reused somewhere at some point, and then someone just has to get lucky once and run whatever
run0 sudo su <reverse shell bs here>to bypass all protections.I agree with you. If i had to add my password everytime I’d just add my personal account to sudo group.
Good security works with people, not against them.
SELinux has left the chat.
Meaning, run0 is overengineered too?
imo it’s kinda like bash’s bloatness. Sure, I’d use a less bloated shell but I need bash as a bash interpreter regardless, so using a smaller shell would actually be more bloat. In a similar way you already have systemd, so you don’t really gain any more bloat by having this alias for systemd-run or how it’s called.
No, like, alternatives to systemd-stuff often do the same job in 1/3 or 1/10 the code.
but with only 1/20 of it’s capabilities lmao
80/20 you know? :) like in sudo vs. doas.
And no. Maybe Runit. Dinit, hard to say. S6 has no need for sockets but still implements it.
Sure, but that is just unnecessary bloat if you already have the systemd-stuff installed.
no? it an alias to systemd-run, you can call an alias bloated
This just sounds like a a solution in search of a problem.
sudo has more than 220k lines of code, I can definitely see the use of a simpler alternative.
Don’t doas already fill that gap ?
Not if no one uses it.
No one will use this either
run0 is just an alias for a part of systemd, so installing doas too would be useless bloat. Another thing to note is that doas is just smaller sudo, you still wouldn’t use 99 % of its features.
edit: also from my totally surface level understanding both sudo and doas “elevate your privileges” which is supposedly unnecessary attack surface. run0 does it in a better way which I do not understand.
sudoanddoasare setuid binaries, a special privileged bit to tell the kernel that this binary is not run as the user starting it, but as the owner. A lot of care has to be incorporated into these to make sure you don’t escalate your privileges as the default interface is very limited, being a single bit.Another issue with this approach is that since you’re running this from your shell, the process will by default inherit all environment variables, which can be convenient, but also annoying (since a privileged process might write into your $HOME) or upright dangerous.
run0doesn’t use that mechanism.systemdis, being a service manager at its core, something launching binaries in specialized environments, e.g. it will start an nginx process under the nginx user with a private tmp, protecting the system from writes by that service, maybe restrict it to a given address family etc. So the infrastructure to launch processes – even for users viasystemd-run– is already there.run0just goes one step further and implements an interface to request to start elevated (or rather with permissions different from their own) processes from a user’s shell.Classic solutions do it like this:
sudo) that runs with root (because that’s the owner of the binary) privileges in their shell. Since this is a child process of their shell, it inherits all environment variables by default.sudochecks/etc/sudoersif that user is authorized to perform the requested action and either denies the request, performs it or asks for authentication.With
run0:run0binary as a user process. This process inherits the environment variables.run0forwards the user’s request via interface to the running systemd process (pid 1 I guess). That process however does not inherit any variables by default, since it was started outside the user’s shell.run0binary is allowed to perform the requested operation and again, either denies the request, performs it or asks for authentication.At least that’s my understanding, I haven’t looked too much into it or used it yet.
the pid1 part is wrong, only the systemd-init run in pid1, in it’s own process, own binary etc, it’s sole purpose is being an init system, after that it start the rest of the system, including the others systemd binaries
the rest is perfect thanks!, in the lennart he made a comparation with ssh were you “forward the commad to run as root”, i think it’s a good analogy
it does that in a “ssh like” that i read in the blog, they foward your commands, they don’t elevate your user, they also use polkit for security intead of sudoers
The original problem was to automagically prompt the user for password, if he tried to run some systemd executable without the wheel privileges. At some point they decided to reuse the code for [a command that allows you to run stuff as root] replacement because sudo is too bloated and vulnerable.
As it is running sudo with a long process is annoying missing and having to reenter my password or missing and the process timing out if I go afk to wait, I can’t imagine having to type my password every few moments when I run an upgrade. Surely this is not the pitch. This is already looking dead in the water if so, and god help me if I have to remember to type run0.
No no no
It’ll be systemctl --user enable --now systemd-run0d
I’m dead
I will use it. I don’t care what others think. People can use su, sudo, doas, run0 by their choice, and I don’t see why we need a common opinion about it.
This. One thing Linux is about is personal freedom.
.
I might try run0 for fun, but I don’t think it’ll replace sudo any time soon.
The biggest issue I see is run0 purposely not copying any environment variables except for
TERM.You’d have to specify which editor to use, the current directory, stuff like
PATHandHOMEevery time you run a command..
You can’t really install packages or modify configs on the host without root. Containers can only do some parts.
I'm not a fan of the idea at all, but come on, it can't really be that bad. There's got to be somewhere you can tell it what environment variables to use. Probably something like
run0 systemd-edit /usr/system/systemd/systemrun/run0-environment --system-default=systemLoL; you say that… But
run0 uses systemd-run i don’t remember you can use that directly
Su - then
Alias it to pull those in automatically?
Maybe, but now I still need to remember the alias or distribute it to any machine I’m working on.
Not that difficult if you have everything managed with Ansible or similar anyways, but lots of people likely don’t have that setup.
.
Is it going to eventually add kernel functionality and become GNU/run0 like systemd? If not i’ll keep using sudo on Ubuntu and doas everywhere else.
No.
You say that, but, lennart’s Cancer is everywhere.
ok them go suffer alone in your 2004 distro that can’t update bash because it break the 400 scripts that it use to boot lmao
Systemd, not linux
systemd/Linux, or as I’ve recently taken to calling it, systemd plus Linux
Fortunately there’s still Artix GNU+Linux :)
They’ve outarched the Arch
Laughs in Gentoo
That’s SystemD+Linux to you!
Prompting for every single command seems like it’d suck
Also, you can configure sudo to prompt every time if you really want.
I was on a system that was configured that way for “security”, so I would just ‘sudo bash’ which is obviously much safer /s.
My system is configured that way (by me) and I regularly use sudo -s.
I just want to see if there’s a root shell and not rely on some hidden timeout 🙄
The beauty of Linux at home, you get to choose what works best for you.
Yeah I mean at that point it’s redundant because you might as well type su -c “some command here”. On the other hand having such alias does no harm if you’re already using systemd.
At the moment, fish doesn’t know what to do with run0. When that changes, I’ll start using it :)
I’ll stick with doas
doass
Speaking of doas, is there any advantage of using it when… sudo is still available to be used? I agree that most of the stuff we require to use doesn’t need all the options sudo as, but if it is for the sake of security, maintenance, and stability… is there any reason to use doas ON TOP of the already setup sudo or su? In the past, I even tried to just apply a simple alias to replace sudo with doas, but numerous scripts and programs when trying to request explicit super-user permissions, just didn’t know what to do with doas as expected, so this ain’t it.
Main reason of using doas
I’ve only found one software like that and it’s tipi, and it’s kinda dumb for a software to require such a easily replacable software. Also how openbsd users are supposed to do ? Having both doas and sudo on their machine which is unnecessary bloat ?
Sure do confirm that hard-coded sudo requirements are kinda dumb. But this proove systemd point. BSD mainly use doas. Linux mainly use sudo. Why not have an universal method for true cross-platform compatibility ? (Yes, I know plenty prefer or explicitly are against the usage of systemd suite of software, was pointing out systemd main reason of planning to propose an another standard, regardless if it will be popular or not)
I like that its configuration file is very very simple.
When was the last time you had to edit sudo configuration file ? Same goes for doas. It’s has nothing going for, for the majority of desktop Linux users (from what I got as an answer)
A month ago or so to be able to use zramen without root password.
Sometimes I really hate the utility names people come up with.
I would love to see chatgpt rename all the core utils in a way that summarizes their function.
The name does do what it says & in just 4 char
I feel like this is well named (run as user 0) so then I’m wondering what else you dislike and what you think would be improvements?
My complaint was mostly targeting the big picture of everything living in
/bin/I inferred the ‘user 0’ thing to their credit like you, it just still felt really strange as numerals are kind of a no no when programming – you can’t begin variable and other names with them and I guess having them as a suffix feels strange too as it’s not common practice.
It will definitely be the only utility I recall that uses a numeral.
To me the whole numeral systems are archaic, User ID numbers don’t line up when transferring data from hard drives from another machine eg 1000-1005.
The numeral permission system is archaic and requires explicit knowledge to know the difference between a 7 6 and 4. In GUI Immutability is separate when it should be more integrated as a file control. The octal permissions are from another decade and modern platforms have permissions on whether a executible can access the internet, access input devices like camera or microphone, or sensitive data like contacts, pictures, etc…
I think file tagging should be greatly expanded, IDv3 meta data for example was a workaround for the limitations and the core filesystem should have robust enough tagging to make it unnecessary.
I’ll be controversial now – eliminate the . prefix to hide files. Yes I know it had been this way for decades and was grandfathered in as a feature after a bug, that should have been in the filesystem properties like chattr +I and you shouldn’t need .hidden indexes to hide files just like windows and osx litters zip files with MDF or inf or whatever (memory is fuzzy from non use).
Some people say “4 character” limit, that needs to go too – FHS naming structure is confusing and not self evident what it does to people trying to learn who already have IT training. /etc/ having 2 or more bins /bin vs /usr/bin – ‘what does usr mean the new it ponders’ ‘oh it must mean ‘user’ I guess’. – weird stuff like that.
To systemd credit they have no problem being controversial and relentlessly persuing their vision in a practical way, hell I use their stuff hapilly.
I just feel like the run0 thing is a band aid on bigger problems, and AI critique would be very fascinating to make these human interfaces you know… more for us humans :P
If not systemd, maybe the rust people or someone else will be baller enough to try to tackle these funny ackward quirks that have accumulated over the years and straighten it all out.
It will definitely be the only utility I recall that uses a numeral.
Utility names should include lowercase letters (the lower character classification) and digits only from the portable character set.
Note that many versions of macOS adhere to these standards: www.opengroup.org/openbrand/register/ www.opengroup.org/openbrand/…/brand3700.htm www.opengroup.org/openbrand/…/brand3705.htm
I know it had been this way for decades and was grandfathered in as a feature
If people were more resistant to “grandfathered” features I think we would not have as much software as we do today: www.jwz.org/doc/worse-is-better.html en.wikipedia.org/wiki/Worse_is_better
It’s probably possible to make several programs with “50% functionality” in the time it takes to make one program with 100% functionality. Having more programs that are suitable for a majority of relevant applications is probably better than having one program that is suitable for all relevant applications, since having more programs will probably enable a larger variety of problems to be solved, and people often have to solve many different types of problems in their life.
what does usr mean
refspecs.linuxfoundation.org/fhs.shtml refspecs.linuxfoundation.org/FHS_3.0/…/ch04.html
Some operating systems may handle long path or file names in a surprising way, so having short paths and names is useful: pubs.opengroup.org/onlinepubs/…/V1_chap04.html#ta…
{NAME_MAX}and{PATH_MAX}are described in more detail at pubs.opengroup.org/onlinepubs/…/limits.h.html#tag… and used in the context of pubs.opengroup.org/onlinepubs/…/pathchk.htmlNote
The resources I linked are
The one that really annoys me is using “-r” and “-R” interchangeably for recursion. Why that has stood is beyond me.
Probably: “oh we already have a
-rfor xxx, let’s do recursion with-R”But it literally is a summary.
It run’s an executable as the user with id 0 (root) and it’s called run0.
I don’t know, we’ll just have to see. But personally, I am not a fan of tying so many functionalities to systemd.
I’m going to continue to keep avoiding Poettering software for as long as he continues to act like a jackass. Even his commit messages are dripping with condescension.
Funny. I didn’t know a single thing about the person. But that commit message made me like him more.
Ofc assuming he was just making a light-hearted joke in it.
Users were complaining that their terminal transparency was being broken by the nspawn container and that the colour for other applications like tmux were being affected by it. For example tmux was appearing in the same navy blue in the terminal emulator instead of its usual green.
Idk he’s just a hot take merchant basically. He has a particular hate-boner for distros that don’t use systemd as the default init system like void and gentoo (usually these are troll tweets as opposed to commit messages though).
shut up, wtf that has todo with the commit, people who don’t use systemd it’s not going to complain about the color of something that they don’t use
lol didn’t realise Poettering had a lemmy account
What an odd and disjointed comment
exactly lol
You’ll have to give another example in order to support your point. Because that commit was funny!
I’m surprised they would implement having just run0 effectively log you in as root. For the super security conscious constrictions of the command versus sudo, it would seem that the very notion of elevating your privilege beyond the single command to be carried out, would be anathema to the whole goal of this new command. Evidently not, but it’s surprising to me.
you can run a command using run0 it’s only elevating that commads, sometimes it’s needed to login as root, it’s life
I’m trying to understand what you just wrote. Did you miss a period somewhere?
They did not miss anything. They just used commas where periods should be.
You can run a command using run0. It’s only elevating that command. Sometimes it’s needed to login as root. It’s life.
The way it is written, semi-colons may be more appropriate but that would be a lot of them.
You actually pointed out that they did, indeed, do miss a period (the one after “run0.”)
su is the best. I mean, i should be using the admin (root) password for admin things, not the user password of user who is already logged in. And there needs to be a root service already running to make user have root previlages which is dumb imo. Sudo vulnerability could cause previlage escalation but if there is no root process managing this, then it can’t leak the root access. Only kernel security issue(or other root processes) will leak root access if that was the case, which i think is better.
Completely agree with this take. There are dozens of us!
The permission to do admin things is given by the root user, to your account. So you have to verify your identity by entering your password.
Isn’t that how it is? I though that was analogous to how almost everything worked IRL. Whether withdrawing funds from a bank or engaging government services, you prove your identity as a customer/citizen to get the relevant services. At no point do you login to bank or government computers with full privileges.
If you own your own bank, then i think you login as the one with full previlages. Yes when doing administrator things, you have to use sudo. The problem with root with sudo is, you authenticate as a user, then gain full permission from root, i.e analogous to login in to bank with full previlages.
As a person who need to run
sudo commandits better to just verify yourself as root user to gain “full access”. I’m not saying about partial previlages. That is i just need a script which is just su -c with environment variables being copiedI see where you’re coming from, but in enterprise environments, you have admin accounts and root login is disabled for security purposes.
Sure. Sudo is a super useful tool in such places. The problem I have is that it is stuffed into the desktop
As the old adage goes: “All roads lead to /root”
.
I’d fedora starts to use it then yeah I’ll use it but I’ll just make an alias cause muscle memory