Back in the day, it was about multiple OS users on one big machine, maintained by a university or a corporation.
Now I'm the only human user of my several machines. I have more than one interactive user account on some of them. I put these accounts to the wheel group, to avoid ever using a root password. (Void Linux has it pre-configured in /etc/sudoers.)
Basically https://xkcd.com/1200/
It's not wheel's fault, and so substituting root group for wheel was nothing more than a special snowflake move by someone who thought the sysadmins were holding back and the "enemy".
Why have multiple different unix users if all have the same power of the root user? They aren't isolated from each other, they aren't less powerful than root. So why not just use the already existing single root account?
Second, it can still be useful for bookkeeping.
Though I suppose, with further thought, it’s not significantly worse than having them in sudoers, in that particular respect.
Back in the day, university campus networks popularized a "cluster" approach of logging in to specific machines whereby hosts followed the pattern: $(uname)[0-9]{2}. You would soon setup authorized_keys and a script that would check the load of all machines by iterating ssh. The same home directory would be shared to all machines, regardless of OS, so portability of shells scripts and POSIX/C code was necessary.
actually if you think about it, lots of machines you OWN nowadays don't give you root access.
For example you can't get access at the actual filesystem on your iphone without a jailbreak.
https://en.wikipedia.org/wiki/Wheel_(computing)
The term wheel was first applied to computer user privilege levels after the introduction of the TENEX operating system, later distributed under the name TOPS-20 in the 1960s and early 1970s. The term was derived from the slang phrase big wheel, referring to a person with great power or influence.
In the 1980s, the term was imported into Unix culture due to the migration of operating system developers and users from TENEX/TOPS-20 to Unix.
By convention, "wheel" is a special Unix user group that determines who can use "su" and "sudo". Most "su" and "sudo" implementations allow the sysadmin to make their use exclusive to the trusted users inside the "wheel" group. In most systems, it's the default setting of "su", and optional for "sudo" (given as an example in /etc/sudoers).
> if someone has the root password, can't they change what groups they're a member of?
No. If "su" is configured to be "wheel"-exclusive, you can't log in as root even if you have the password, because you cannot use "su" - unless you have direct access to the system console that allows you to type "username: root", which is almost never the case on servers that disable remote root login.
Users who aren't in the wheel group aren't supposed to be able to become root, even if they have the password.
Isn't it just supposed to switch user? And what are the implications of not-checking whatever it was supposed to check?
Someone who steals the root password (say, by looking over the sysadmin's shoulder) would be able to become root.
And I also don't get: if someone has the root password, can't they change what groups they're a member of?
No, because they can't log in as root and (on non-broken systems) can't become root.
Or is the wheel group not really about being able to sudo?
It removes the section at the bottom of the man page, and has this addition to the source code comments:
+#ifdef USE_PAM
+
+ Actually, with PAM, su has nothing to do with whether or not a
+ wheel group is enforced by su. RMS tries to restrict your access
+ to a su which implements the wheel group, but PAM considers that
+ to be fascist, and gives the user/sysadmin the opportunity to
+ enforce a wheel group by proper editing of /etc/pam.conf
+
+#endif- it makes it smaller, less code which can go wrong
- su isn't limited to "set user root" but wheel tends to be
- it avoids having to handle many kind of subtle problems with group based permission handling in linux
It's just not a bad idea to have a very minimalist program like su and then delegate all more complicated "acting as user" permission handling to other programs like sudo or doas.
Through tbh. the more I do learn the more I come to believe that uid/gid based permission handling is fundamentally flawed (but also good enough inside of a single application OCI(docker) image). The facts that Linux had to add a (very limited) capability system or that enterprise permission handling often goes through stuff like pollkit adding additional handling then just "gid/uid match" is I think very telling.
Have you seen the number of flags every command has? ls has almost the entire alphabet taken.
“9.5 Case Sensitivity There are 66 useful settings that affect case sensitivity, plus 10 settings that are nearly useless, with the remaining 116 settings being either redundant or useless.”
https://gcc.gnu.org/onlinedocs/gcc-3.4.6/g77/Case-Sensitivit...
I think the convention itself is good - I prefer long flags in scripts for improved readability.
But GNU is anything but minimal - compare GNU ls[1] with BSD ls[2], and try to recall the last time you needed --dereference-command-line-symlink-to-dir.
[1]: https://linux.die.net/man/1/ls
[2]: http://man.openbsd.org/lsSo true. I remember early on when GNU was started, people in the project where saying and developing with something like this in mind (paraphrasing):
"Make sure it works and meet users needs, even if it is too heavy for current systems, the hardware will improve as time goes on"
And that came true, for example, emacs is a lite ballerina compared to current IDEs.
I guess there are ways that sudo/doas could be adapted to implement passwd, chfn, chsh and friends, but the approach appears to have been chosen in the '70, and codified by POSIX.
How do you think these should be implemented?
It was a different world, and having some basic speed bumps like not allowing random user accounts to su to root was useful at the time.
And what was allowed by the social norms of the tiny 1980's *nix computing world, or what you can get away with when you're as famous as Mr. Stallman...those may not translate well to other contexts.
I used to think Stallman was an ideologue from a different era. When I started dealing with software projects measured in years and millions his thoughts made much more sense to me. When you're selling me a system that has a 6/7 digit implementation cost for it to stand any chance of meeting my goals, withholding the source code only serves to annoy me.
I do understand the point of view when I think back. Today, Unix-like systems are everywhere. Learning it and working with it is a given. Back then, having access to a unix system was not a given. It was very expensive for hardware and software. The idea that one would be so close to the system and could be denied enough access by an overzealous BOFH was too much to take.
It just goes to show that circumstances change, and things can get weird if we don't change with it.
One of my favorites is extensive rights management. Especially on CMS. More ofte than not it is part of a buying decision, but used Stallman style soon after.
The observation that these credentials leak is correct. Or that you grow permissions over time for no other reason than doing work. A wheel group would today quickly attract users, too.
So let it be. The latest iteration is "basically let everyone, but audited and short term only". I find that very close to Stallmanns idea, for very different reasons.
And that person may not be the systemadmin
Similarly, Stallman's coding expertise can sometimes overshadow any potential shortcomings in the non-IT subjects.
Should this be that far-fetched though? That employees might not be simple thralls of the capitalist, whose agency extends only as far as his master permits?
It reminds me of something I'd read that one of the reasons modern capitalism is so borked is because the founding fathers weren't conceiving of things like "Amazon" existing, where one entity employs a staggeringly large number of employees. Or that a small number of companies would employ such a large percentage of workers.
Their worldview was that where most people were "self-employed" - and if they weren't, employers were small and had a few or tens of employees at most. Or it was a matter of master and apprentices where both groups were investing heavily in each other in a trade and in the running of a shop.
So, while yes our current system finds it a matter of course that employees are utterly subject to the whims of their employer and the legal and economic system fully supports them in this, does it have to be that way?
(I know you can go be a contractor, but good luck with health insurance and etc etc etc all the other things that being yoked to an employer brings that I wish were just public taxpayer-funded services).
I'm not quite sure I buy that argument. They lived in the time of the East India Company, which owned something like 50% of the world's trade at the time and ruled several nations.
It's easy to get someone in trouble in either case. If the user foobar starts doing crazy stuff as root, then foobar is in trouble. If you get the root password and start doing crazy stuff, then your username is associated with the troublemaking. (Assume that the logs go to some machine where you don't have access to remove them.) RMS's mechanism shifts the responsibility for your actions onto you, so that someone who knows the root password is more likely to leak it to you.
The best of both worlds is to get the root password, then find a hapless coworker who left their screen unlocked while out to lunch. su with the root password there, cause your chaos, everyone blames lunch guy. (Do look for outside systems; people and cameras can see you using someone's computer. Was always funny to me how many people have tried something like this, only to be nailed by the security cameras.)
You either have the password, or you don't have it. But not something in-between.
Outside of any ideology, in a scenario where you use su to become root, it's a very odd choice to link the wheel group to su; because if you know the password to the "root" user, and you have physical or remote access to the computer, you can likely just login as root.
And if you can't, then it means you actually needed sudo su, not su.
Those who actually need to be root, usually use sudo instead of su.
In the other cases, if you just need to switch user, then no point at all to refer to wheel
and let sudo verify that the user belongs to the group of allowed sudoers.
No need for the password to the root account.