Why linux doesn't have a "wheel" group | Hacker News Reader

Why linux doesn't have a "wheel" group

administratosphere.wordpress.com

118 pointsj_baker62 comments

A simpler explanation is that many Linux distributions discourage the use of su altogether in favor of sudo, which gives you finer grained control over this sort of thing than wheel ever did.

In any case, if you really care, just enable pam_wheel.so in your pam configuration for su (usually /etc/pam.d/su) and be sure to add yourself to the appropriate group.

Ironically, "sudo su" works really well if you do need to get to root. But yeah, "sudo" is a much safer practice.

"sudo -i", please!

sudo vi^Mpassword^M:shell

Years ago a friend of mine asked my help in securing a Unix system with sudo. I bascially told him it was nearly impossible because there were (and still are) too many ways to escape back to a root shell with sudo, so, in my humble opinion, gives a false sense of security.

But as far as letting people run a root shell goes, sudo is a handy way to do it.

I don't think the point is "more secure" root access. Rather, sudo is just a convenient way to invoke superuser privileges only when necessary.

If you need a longer session with uid 0, use sudo -i. Having a separate root login is pretty much pointless. I doubt having separate passwords helps security either, since local privilege escalation vulnerabilities are common anyway.

I've used sudo to restrict root access to specific command line invocations for certain users. With due care (ie. no access to software with shell escapes) it is secure.

In any case, distributions seem to be moving towards eliminating the superuser altogether in common use cases. I think advocating sudo was just the beginning.

start by disallowing vi through sudo and tell people to use sudo -e instead

I sudo su very frequently because I'm almost always executing more than one command as root. Standard warnings apply, but my approach for being sure that I am who I think I am is to put my username in my prompt and color code it so that when I'm root the username turns red.

I also color code the hostname so that I can tell at a glance what machine I'm on.

For example,

    export PS1='[\[\033[1;34m\]\u\[\033[0m\]@\[\033[1;30m\]\h\[\033[0m\] $newPWD]\$ '

where $newPWD is a friendly, shortened $PWD.

On that same machine, the root prompt is identical except that the color is set to 1;31m instead of 1;34m, which makes it bright red.

No need for 'su' to get a root shell. You can use 'sudo -s' for that, and you still set a root-specific PS1 in the bashrc file.

This doesn't always run the same rc scripts (depending on the shell and local convention). I'm used to typing sudo su - (with optional username) to get the environment as close as possible to what it would be if I logged in as the target user.

  alias ssu='sudo /bin/bash -login'

sudo -s launches a shell in non interactive mode (which goes through .bashrc or .zshenv and .zshrc depending on your shell) whereas sudo -i emulates a usrer login which puts the shell in interactive mode (.profile, .zshenv)

Also -i does more stuff to simulate a login like setting $HOME and cd'ing there.

Usually you might want to use sudo -i or 'su -' which both simulate a login. But sudo su - really isn't needed any more since -i has been added

Old habits die hard.

I have generally found the difference between a $ and # prompt sufficient enough. I guess colours can't hurt though.

If you have a saddist sysadmin he wouldn't allow you to use su or any other dangerous command that are not approved. Sudo is a rather impressive tool. If you need to give someone access to root for one or two commands, it can do that. It's logging ability is lost when you do sudo su. You should avoid it as much as possible on servers with many admins. That log trail can be a real butt saver.

sudo $YOUR_SHELL_NAME_HERE achieves the same purpose.

`sudo -s` works nicely too.

Or you can just use "sudo -i"

While this may be true today you cannot use it to explain the history of this decision.

My recollection is that when OSX came on the scene without a root password and administration through sudo, Linux distributions were still tied to root and su and many Linux users were both disapproving and condescending about it.

Many still feel this way. Don't let the pre-eminence of Ubuntu fool you -- most Linux distros, afaik anyway, still include root as a first-class citizen with its own password and everything.

I do think that the disapproving and condescending attitude to sudo has changed though.

Many Linux distributions being Ubuntu & friends? Fedora or RHEL don't promote sudo like Ubuntu does.

If someone wants to work in a root shell, I think it's fine provided they understand the damage they can potentially do. It could certainly be possible to habitually prepend commands with sudo, particularly if you need to type many of them.

Though certainly it's safer to do some tasks as non-root as well, such as compiling software, then switch to root/sudo to install it. Just remember to double/triple check each command you type in a root shell or after the sudo command. Particularly when using commands such as rm with arguments such as -rf!

Sudo also does provide some extra flexibility when you are delegating tasks to someone who doesn't necessarily need full root access.

It's actually interesting to consider Stallman's point. In a way, his ideals are ultimately incompatible with shared systems. A user should have their own resources if they're going to be Free. You can't have all of shared resources, security, and total Freedom in the sense of Stallman.

Application to the swing back to "cloud computing", multiuser computing's latest moniker, left as an exercise for the reader.

Don't forget that this info page was written something like 20 years ago - or even earlier.

At this time security requirements where completely different than today and it was not unusual for everyone in a lab to have root access to the machines.

I really miss the time when you could assume that, if someone had access to your computer, he or she was qualified to properly operate it.

I really miss the time when I felt that I was properly qualified to operate my computer.

Linux systems generally (the last time I ran Linux was about half a year ago) don't have any sane ulimits set up either, they allow any user to forkbomb the system into oblivion. Whereas with FreeBSD the ulimits are set up for users so that they can't take down a system with a fork bomb.

If Stallman were here, I'd imagine his response would be something along the lines of "Sure, it's less practical to do things this way, but it's the right thing to do. It's not right to give other users Carte Blanche to bully others any way they please just because they have a different job title."

I'm not sure I understand Stallman's comment. He is against letting "a few of the users ... hold total power over the rest". Isn't that the whole point of a system administrator? He seems to be explicitly in favour of making it so that a leaked root password will allow any user to run riot over the system. Is he an anarchist? Or did they not have malicious users or idiots in 1984? I admittedly know almost nothing about system administration.

From "Free as in Freedom: Richard Stallman's Crusade for Free Software":

---

"The hackers who wrote the Incompatible Timesharing System decided that file protection was usually used by a self-styled system manager to get power over everyone else," Stallman would later explain. "They didn't want anyone to be able to get power over them that way, so they didn't implement that kind of a feature. The result was, that whenever something in the system was broken, you could always fix it."

Through such vigilance, hackers managed to keep the AI Lab's machines security-free. Over at the nearby MIT Laboratory for Computer Sciences, however, security-minded faculty members won the day. The LCS installed its first password-based system in 1977. Once again, Stallman took it upon himself to correct what he saw as ethical laxity. Gaining access to the software code that controlled the password system, Stallman implanted a software command that sent out a message to any LCS user who attempted to choose a unique password. If a user entered "starfish," for example, the message came back something like:

I see you chose the password "starfish." I suggest that you switch to the password "carriage return." It's much easier to type, and also it stands up to the principle that there should be no passwords.

I can't conceive of a world where "there should be no passwords" or "keep these machines security-free" were ever serious positions held by software engineers. It's Garden of Eden thinking.

It wasn't a rationally-considered position, it was a reaction against the strict hierarchy and batch processing mentality of the time. (Disclaimer: everything I know about this I learned from Stephen Levy's book Hackers.) The admins of these machines would flaunt their power over the users, and were very antagonistic toward the hackers who wanted to do "cool" stuff on the computers. So, keeping the machines security-free and not allowing passwords was actually necessary to promote the idea that anyone could run a program on the computer, because that was not the status quo.

The fear that someone would take control and abuse power in that way was not an unfounded one.

Right, perhaps it was a different time, but you need to limit the power of most users, especially in a school setting, or you cannot maintain the uptime of the system for everyone.

I know in our computer lab in high school, which was a series of x86 PCs donated by Novell and sharing files from a Netware file server (this was 1989-1990), we used to try to get superuser privileges on the Netware server. Once or twice, the 20 year old kid they hired as a sysadmin would walk away from his desk and forget to logout of his workstation, and we would give ourselves superuser privileges on the network. We would use this privilege to play "Snipes," one of the first network based multiplayer text shooter games. http://en.wikipedia.org/wiki/Snipes

This fun lasted for a few hours until the 20 year old sysadmin determined we had superuser privs that we shouldn't have and promptly revoked our rights.

ha ha - that's funny. We had a very similar setup at the same time - the workstations were "diskless" and the only way to get software onto the machine was to write it (in Turbo Pascal). The workstations were 8086's while the file server was a 286, and the other server was a (then very expensive) 386.

But the admins had installed "NetWork Eye" - sort of like a VNC for text monitors. So one guy in the class wrote an assembler (in TP) then got a NetBios book and wrote some low-level NetBios stuff in assembler. That allowed us to NetWork-Eye the servers to get some other funky stuff done.

One thing we did was to login on all 50 workstations (except one), and run the network eye in a cascaded chain. Then sit back and watch the first person come in. They're log in (on all 50 monitors simultaneously) and everything they did would come up on all 50. Usually took a few minutes before they noticed...

Ahh - good times.... <g>

That's similar to how parents can't think of a world where they would let their unprotected child walk 500 meters to the school nearby.

Those system did not have network access at first and when they finally did most of the people on the net at the time were know (small community) and peer pressure kept people in line. ITS had a easy command that would kill and shutdown the machine. This took all the fun out of hacking the machine and killing it. There was always a loser that would try it and he would forever be forsaken by the Hackers.

Read Hackers by Steven Levy. I read that book every year almost.

>There was always a loser that would try it and he would forever be forsaken by the Hackers.

So everything was great until the dumbass showed up and ruined everything? This makes a great argument for account privileges and security.

Because it's human nature to push that big, red button...

Well in the end the frequency of someone pressing the red button went down as the challenge was pretty much eliminated. You're looking at it as if the glass was half empty. It's not perfect but it allowed them maximum freedom to play with small downsides of troublemakers.

This obviously wouldn't work today but back then the culture of the users was very different.

To be fair, we did have that world in the late 90's. It was called Windows 98.

That world did exist. In the 1980s my password to the campus timeshare unix system was ]]. The system required at least two characters, and these were the closest to the return key.

Many people's passwords were known. I trusted nobody to rm everything, and nobody ever did.

The internet changed that.

The internet changed that, eventually.

I'm the mid-90s I worked at a UK university computer science department. At the time there were no firewalls around the departmental network and pretty much every machine, from the Sun and SGI workstations through to the multi-CPU servers, were directly connected to the Internet. We used NFS, rlogin and co. to transfer files and connect to different machines. I can remember logging into machines remotely from home using a modem, an ISP and passwords-in-the-clear. There was no regime I was aware of to apply software patches to machines.

Looking back, I can't believe how much of a trusting place the internet was back then.

Multi-user computers are far less important now than they used to be. With systems that compose clouds, you might want the linux kernel and IPC but you don't care about unix permissions models.

I'd like to work on a totally open system where users could clone one another's blocks of memory and see everything. You could come up with a more collaborative environment than we have in unix atm. However, I wouldn't want an arrangement where one person's slip of the fingers could destroy the environment.

If the computer isn't connected to the internet and doesn't have private information on them then it doesn't seem to matter if there is a password or not.

Don't forget these machines were in a much safer environment than todays.

> limits the number of people who are able to su to root.

Is irrelevant and archaic for many, many servers (99%) of ones I've worked on last 20yrs (web/internet servers vs file/print/lan type servers.

The only accounts who can login and get a shell are the same set of accounts who can su root to almost every server I'm involved with.

That may be true of servers, but there are lots of uses of Linux besides servers...

As a database consultant I can assure you there are great many servers on which I have a user, but no ability to "su root".

I bet if you were an "evil database consultant", you could get yourself a root shell on _many_ of those servers with a little bit of google fu. There is a startling amount of exploitable code waiting in just about every standard OS install for anybody with regular user privileges.

If I was evil and suicidal I could wipe up many companies by "drop database including backup".

When you have DBA access to production databases, lack of root does not stand in the way of doing evil.

It does stand in the way of using message logs to troubleshoot, checking contents of /proc to determine which directory a process is running from, tuning TCP parameters to maximize data transfer rates without nagging the sysadmins, etc.

True. But a _properly evil_ non-suicidal and supremely confident evil DBA could, if they wanted too, exploit the box from a local user account, rootkit it, and tidy up after themselves to remove all trace of who did it. I suspect that's actually script-kiddy-able these days, if you know the target well enough there's probably an automated tool ready to do all that for you.

(For evil-genius-DBA's bonus points for doing that via the database instead of the shell and censoring traces from the db logs too...)

On everything I'm responsible for, it's assumed that if you've got shell or if you've got permission to upload executable code, you've got the ability to get root.

I'm prepared to keep on top of server security enough to protect against remote-root exploits (with reasonably short zero-day exposure times), but there's no way I'm going to be able to keep every little utility shipped with a useable linux distribution up-to-date and secure.

If Tripwire or Snort or the logfiles show unexpected filesystem changes, we reimage the OS and restore the data from backups.

Ironically the "wheel" construct is alive and well via sudo. The default /etc/sudoers for rhel/centos/fedora systems has a line that allows anyone in the wheel group the ability to run anything they want through sudo, its just commented out. Delete one character and voila, you can give and retract root privs via adding and removing users from the wheel group.

I noticed recently that my Debian now comes with a "sudo" group that is effectively the same thing.

That's because sudo is a BSD tool so it's always worked with the wheel group.

In my Slackware system, which does not use PAM by the way, it's perfectly possible to support the "wheel" group. In fact, the group is already present in /etc/groups and you can add users to it. Later, you don't need to change the permissions of /bin/su. The check can be run from the program itself if you edit /etc/suauth and add a line like this:

root:ALL EXCEPT GROUP wheel:DENY

But I think this may be due to the "su" program not being GNU su, but the one from the shadow suite. :)

The title is incorrect on several levels. Not the least of which is that it is the distributions that determine whether to use wheel, not the Linux kernel.

For example, in Fedora 15 we are now using wheel to add users as administrators who are able to sudo to root. This is easily enabled by checking the 'Administrator' box during firstboot's setup of the user account.

Nitpick about the title: "linux" is a kernel and doesn't care about how the userspace organizes its groups.

It's really about GNU su.

So why allow for a root password in GNU at all? Is Stallman really saying that everyone should have root access?

If you accept that there's a use for a secret root password (which, I assume, Stallman has; otherwise why write an `su` at all?), having no wheel group would seem to encourage a /single/ admin with the password, to prevent the leaking of info he mentions. Which is more tyrannous?

su has uses even when everyone knows the root password. It allows you to run a command as a different user without logging out.

I also am not sure that Stallman accepted the need for passwords at all when he wrote that text. http://en.wikipedia.org/wiki/Richard_Stallman:

"When MIT's Laboratory for Computer Science (LCS) installed a password control system in 1977, Stallman found a way to decrypt the passwords and sent users messages containing their decoded password, with a suggestion to change it to the empty string (that is, no password) instead, to re-enable anonymous access to the systems"

This logic only makes the tiniest bit of sense if 'su' is the only way escalate privileges. Almost every real system has many ways to escalate, especially for someone who already knows the root password. telnet, sudo, X11, ftp, and last but not least, 'login'.

"OK", you say "maybe all those are turned off for root". Well, even then there are likely many other accounts with some degree of privilege. Often these can be leveraged to root access. For example: the members of the wheel group.

The etymology of the company WheelGroup (now aquired by Cisco) makes a lot more sense now... http://en.wikipedia.org/wiki/WheelGroup

Strange, most distros I've used do have wheel. I think it's only Debian based distros that don't.

I've used Gentoo for years and it used the "wheel" group. Maybe it has changed now, though.

Reply on news.ycombinator.com