Sudo rant

[blackhole]

High levels of confirmation bias politics in here.

sudo(8) was developed by Todd C. Miller (an OpenBSD developer) and released under a permissive licence.

I think much of the hate for it comes from the classic Ubuntu style implementation as a root/su replacement - e.g. this kind of thing:

# Allow members of group sudo to execute any command
%sudo	ALL=(ALL:ALL) ALL

A previous poster in this thread did link to some literature on the subject (some by Michael W Lucas).

Personally I prefer su(1).

sudo is useful if you want to give someone some very specific permissions without giving them full root privileges. e.g. if you need so allow someone to ssh into your server and restart a specific daemon for example.

 

[rbranco]

Personally I prefer su(1).

sudo is useful if you want to give someone some very specific permissions without giving them full root privileges. e.g. if you need so allow someone to ssh into your server and restart a specific daemon for example.

sudo & su are very different programs with quite different goals.

You can use sudo in scripts while su is for terminal use.

 

[Zare]

su and sudo are interfaces to the same mechanism, setuid, almost as old as Unix itself, with it being written as kernel counterpart of su.

Setuid allows us to run escalated processes as limited user, with the process itself doing the privilege control any way it wants.

On top of this builds su, for interactive shells, and sudo, for commands.

For example, if you wish to run Steam and be secure you run it under a different user. If you want to simply enter in, or click into Steam, you will need to switch users per set rules, and this is where sudo kicks in. Without it there are no seamless ways to perform this.

(everything written for sudo doubles for doas)

 

[astyle]

Yeah, if you want some finer-grained control, then there's no way around getting deep into learning how the privilege elevation mechanism even works, and what options are available. For some use cases, that's a sore necessity, and for others - merely a convenience that does require some fine-tuning. If that convenience is not tuned correctly, though - that can really bite, and we're stuck between deciding if it's better to open the floodgates or shut them completely.

 

[irritum]

Artix, Void, Devuan

perhaps try gentoo? or like you said it yourself avoid “lunix” altogether as much as possible - the problem with that is in past couple of decades it has become practically as ubiquitous as ms winblows once was (coincidentally also about 20 years or so ago) and embraced by corporate integrators virtually everywhere. as a result it is essentially impossible to avoid all interaction with it completely just like it was impossible to avoid all contact with ms winblows in late 90s - early 00s…

 

[Espionage724]

perhaps try gentoo? or like you said it yourself avoid “lunix” altogether as much as possible - the problem with that is in past couple of decades it has become practically as ubiquitous as ms winblows once was (coincidentally also about 20 years or so ago) and embraced by corporate integrators virtually everywhere. as a result it is essentially impossible to avoid all interaction with it completely just like it was impossible to avoid all contact with ms winblows in late 90s - early 00s…

I was trying hard recently to run my webserver stack on all-Windows, but something had a php-posix requirement. I figured out the minimals for WSL and the Linux distro I came from, copied my PHP set-up (bare-metal to WSL), tried dozens of variations of nginx and proxy_pass stuff, and figured out how to have just that website's PHP going through WSL php-fpm while keeping everything else on win32 nginx and php-cgi! It was fun

I did learn an interesting trick though to not run php-fpm master as root like every Linux distro and FreeBSD (iirc) do out-the-box (along with not needing a master process at all!). sudo was annoying enough off-Windows that I did everything unelevated on Windows, so sudo kind-of encouraged a better security habit I appreciated more on Windows

 

[sidetone]

sudo(8) was developed by Todd C. Miller (an OpenBSD developer) and released under a permissive licence.

A previous poster in this thread did link to some literature on the subject (some by Michael W Lucas).

We weren't complaining about any of that. I have one of his ebooks. It was something unrelated to su, sudo, doas, any access control and his books that had no business being brought up.

Personally I prefer su(1).

sudo is useful if you want to give someone some very specific permissions without giving them full root privileges. e.g. if you need so allow someone to ssh into your server and restart a specific daemon for example.

I use doas, but sudo may have been the inspiration and blueprint for doas. Also, su may have been inspiration for sudo and doas.

 

[recluce]

Guys, learn about "visudo". It is up to you if a password is needed with sudo. While I cannot recommend turning off the password requirement in general, it can make a lot of sense to disable the password requirement for certain commands. visudo behaves in a similar fashion on FreeBSD and most Linux distros.

 

[blackhole]

We weren't complaining about any of that. I have one of his ebooks. It was something unrelated to su, sudo, doas, any access control and his books that had no business being brought up.

The original post appears to take the form of a rant against the Ubuntu style implementation of sudo in some Linux distribution. I posted the information about the developer and licence, as many Linux users have assumed sudo to be an Ubuntu / Linux thing in the past, so I don't think it's harmful to get that "on record".

So in my view, the documentation and further reading seems relevant. (Incidentally - the documentation and further reading does seem more on-topic to the thread compared to political opinion pieces interspersed throughout.)

 

[epower53]

Okay, here:

My rant for tonight- sports betting needs to go. I just want to watch a football game without being constantly bombarded with ads for gambling apps. I work too hard for my money to throw it away... you'd think with all the back-end consumer spying the big tech companies are doing they'd figure out that these ads aren't working on me and just give up.

 

[Espionage724]

My rant for tonight- sports betting needs to go. I just want to watch a football game without being constantly bombarded with ads for gambling apps. I work too hard for my money to throw it away... you'd think with all the back-end consumer spying the big tech companies are doing they'd figure out that these ads aren't working on me and just give up.

It might work something like the ads getting annoying enough that you'll just try it eventually (and get hooked and/or like it)

Afaik bet ads mention non-exportable starter credit, and I'm thinking that short "free" time period is enough for the hook or like; I don't have the time to want to find out

 

[epower53]

annoying enough that you'll just try it eventually

I hold grudges basically forever. They're on my naughty list and have no chance of getting off it. I'd actually pay extra to go back to ads for beer, cars, and food, and nothing else.

Edit: also, get off my lawn!

 

[cy@]

High levels of confirmation bias politics in here.

sudo(8) was developed by Todd C. Miller (an OpenBSD developer) and released under a permissive licence.

I think much of the hate for it comes from the classic Ubuntu style implementation as a root/su replacement - e.g. this kind of thing:

# Allow members of group sudo to execute any command
%sudo    ALL=(ALL:ALL) ALL

A previous poster in this thread did link to some literature on the subject (some by Michael W Lucas).

Personally I prefer su(1).

sudo is useful if you want to give someone some very specific permissions without giving them full root privileges. e.g. if you need so allow someone to ssh into your server and restart a specific daemon for example.

We use it at $JOB to grant customers to manage their own apps. Linux capabilities can replace sudo to an extent, though there are limitations. And in the hands of an inexperienced sysadmin sudo can render the system as if it was virtually compromised.

It's not the handy be all and end all that most people think. It's rules are buggy and arcane to most people, easily exploited. But, it's the only thing we have, save a few other less well known and less capable tools out there.

When I was working for $JOB-1 we used Kerberos. All sysadmins would get their TGT in the morning. It expired ten hours later. Again, customers got carefully designed sudo rules.

None of this, su, sudo, UNIX permissions, and ACLs, compares to the tools we had on the IBM mainframe (RACF and ACF2). UNIX was never really designed for comprehensive security in mind. No matter what we do to tweak the security paradigm, whatever we do are still add-ons to the basically open security architecture.

In the hands of a sysadmin without intimate knowledge of each and every command, i.e. vi and more among others which one can escape to a shell, sudo is a dangerous tool.

 

[ralphbsz]

None of this, su, sudo, UNIX permissions, and ACLs, compares to the tools we had on the IBM mainframe (RACF and ACF2).

Had, and still have: zOS is still shipping, and while it is a tiny part of the overall computer market (which is nearly completely dominated by iOS/Android machines in people's pockets, Windows machines on their lap or desk, and Linux machines in server racks), it is a large part of the market where it matters: banks and insurance and government for the "systems of record".

Even other minicomputer operating systems of the same era as Unix (such as VMS) put much more thought into security. For example, VMS had the ability to have a "root in group" user: Someone who was a superuser, but only for entities in their group. That alone removed 90% of the need for su.

UNIX was never really designed ...

You can end the sentence there. Many of the basic design decisions (such as the shell being an unprivileged user program, and files/directories having only 9 bits of access permission flags) were coincidences or conveniences of a research prototype that was not intended for real production, but they stuck so much that they couldn't get changed.

Maybe ultimately the VM-ification of everything is the solution: Just give each user their own VM, and within that they can do whatever they bloody like, including being root. Leave sandboxing and security enforcement to the outer layer, the VM host. This worked pretty well for IBM's VM/CMS operating system.

 

[loveydovey]

UNIX is about getting what you asked for without holding your hands. And rm -rf / is so much fun... well, sometimes.

Speaking of rm -rf /...A couple of days ago AI did this to me, well, almost. This is a forewarning to all about the dangers of AI. The struggle is real!

So, I was getting Gemini 3 to help me write and improve a jail script. And it would normally spit out the entire script back. It conditioned me to think it was the entire script it'd output. Then it outputted a snippet instead of a full script, I copy/pasted it, ran it, and the next thing I know my /etc/ folder is largely wiped out, can't log in or do anything suddenly.

The code snippet had

rm -rf "${JAIL_PATH}"/etc

as part of cleaning up, which works fine as part of the full script, with all checks in place, but as a snippet that didn't set the jail path, it just did

rm -rf /etc

. Hahaha. Never get complacent with AI.

 

[scottro]

epower53 take a look at the Daily Show's sports war. (Easy to find on youtube). It's basically a 5-8 minute segment, interrupted all the time with the (silly title) bet of the day, usually consisting of one commentator insulting the other, and it ends with
Brought to you by Gambling. Gambling, the FUN way to lose your house (or some other slogan showing how silly people can get, gambling). It's worth a chuckle and you might enjoy their poking fun at the plethora of betting ads.
Or, as one other old joke goes---The lottery---taxes for people who are bad at math.

 

[cy@]

Had, and still have: zOS is still shipping, and while it is a tiny part of the overall computer market (which is nearly completely dominated by iOS/Android machines in people's pockets, Windows machines on their lap or desk, and Linux machines in server racks), it is a large part of the market where it matters: banks and insurance and government for the "systems of record".

IKJEFT00-IKJEFT07, the group of modules that comprise the terminal monitor program, what is known as TSO, is also unprivileged. The shell should not be a privileged app.

Even other minicomputer operating systems of the same era as Unix (such as VMS) put much more thought into security. For example, VMS had the ability to have a "root in group" user: Someone who was a superuser, but only for entities in their group. That alone removed 90% of the need for su.

Of course they did. Those weren't toys at the time.

You can end the sentence there. Many of the basic design decisions (such as the shell being an unprivileged user program, and files/directories having only 9 bits of access permission flags) were coincidences or conveniences of a research prototype that was not intended for real production, but they stuck so much that they couldn't get changed.

UNIX was an evolution. A WIP. It made do at the time. But then again so was the Intel 8080 line of processors. We live with that legacy today as well.

On the mainframe side they still must contend with 24- and 31-bit modes, both of which greatly impact the architecture of the 64-bit zSystem. Legacy and history are there to haunt us and future generations.

Maybe ultimately the VM-ification of everything is the solution: Just give each user their own VM, and within that they can do whatever they bloody like, including being root. Leave sandboxing and security enforcement to the outer layer, the VM host. This worked pretty well for IBM's VM/CMS operating system.

CMS is a simple toy, like MS-DOS was. Having run MVS under VM many times, that was the real power of IBM's VM. In yesterday's environment that was fine. But letting a user have full root access on a VM is a different matter. Unless you put them on their own network segment or VLAN, away from all other work or user managed VMs. VMware's NSX is a good implementation of that.

 

[cy@]

ralphbsz, one more thing to add. As much as we love to complain about UNIX, the alternative on the desktop is much worse. I'm in the process of rebooting my employer's W11 laptop, because the browser won't hit an internal website. And you know, too many apps, like browsers , have hooks in the Windows kernel, like rendering fonts in kernel mode. Like, what could possibly go wrong with that?

A frustrated Windows user at $JOB.

 

[ralphbsz]

As much as we love to complain about UNIX, the alternative on the desktop is much worse.

Absolutely true. We can argue about bad (or absent) design choices made 50 years ago, but the reality is that every single computer in my house (and at my office) runs some flavor of Unix. Even the Mac I'm typing this on. While I still have to VMS machines in the basement (two small VAXen), they haven't been booted in years, or perhaps a decade. And the cp/m machines are completely packed away in cardboard boxes, and it would probably take a month to get them back to work.

Today, the only alternative to various Unix flavors at the consumer level is Windows. For many people it is an excellent choice, for others not so much.

 

[Espionage724]

...like rendering fonts in kernel mode. Like, what could possibly go wrong with that?

There's a group policy to force system-only Fonts, and I made it a habit to go under Personalization -> Fonts and have it download every language font officially

 

[cy@]

There's a group policy to force system-only Fonts, and I made it a habit to go under Personalization -> Fonts and have it download every language font officially

You misunderstand. You can disable apps ability to load their own fonts but it still doesn't mitigate the problem. That the font rendering code is in the kernel, the wrong place from a security perspective. And fonts are not the only issue. There are a number of interpreters in the Windows kernel. Kind of like running your shell in the kernel.