Why is root in wheel and operator? Can root being in a group ever make a difference?

Question

I just noticed on my FreeBSD machine that root is in wheel and operator. I'm trying to think of a situation where UID 0 being in a group would have any effect on... well... anything, and I'm coming up blank. For that matter, does root even need a primary login group in /etc/passwd? Or does login(3) choke and die if the user has a blank primary group field?

(To clarify: I understand the purpose of the "root" group's existence, since files need a group owner. I'm not understanding how it matters that the user root/toor/whatever has that group membership.)

Is this just cruft from decades ago, or is there a real reason for it?

Answer 1

In short: no. Having root on wheel and operator group change nothing.

But you are also questioning 2 other things:

• root group id is (by default) set to 0, which is closest thing to a empty value you can get.

  $ head -4 /etc/passwd
  # $FreeBSD: releng/9.2/etc/master.passwd 243947 2012-12-06 11:52:31Z rwatson $
  #
  root:*:0:0:Charlie &:/root:/bin/csh
  toor:*:0:0:Bourne-again Superuser:/root:
  

  As said, every user has to have a group, so you cannot set root group id (nor any user gid) to a void or blank value. If you try to set a user gid to blank, you will be warned by pwd_mkdb:

  pwd_mkdb: no gid for user root
  pwd_mkdb: at line #3
  pwd_mkdb: /etc/pw.Rlb2U3: Inappropriate file type or format
  re-edit the password file?
  

  So the fact that root is defined is more about having it properly named instead of just a dumb number. You can change root gid to any meaningless number (gid not within /etc/group). Your root user would still be able to log in, su or whatever else root can do. You will just end up have something like that:

  $ id
  uid=0(root) gid=10000 groups=10000,5(operator)
  

• about why some users are in the wheel group that is a totally different story, as FreeBSD, like OpenBSD or NetBSD, users have to be part of the wheel in order to su root.

  From FreeBSD documentation (chapter 9.4):

  To su to root (or any other account with superuser privileges), you must be in the wheel group. If this feature were not there, anybody with an account on a system who also found out root's password would be able to gain superuser level access to the system. With this feature, this is not strictly true; su(1) will prevent them from even trying to enter the password if they are not in wheel.

  But you are right, removing the root user from the wheel would not change things. This is purely formal, as much as the toor user is nor part of wheel or root is part of operator group.

• The operator group is however, purely formal, without any special meanings in itself.

Here is also what Richard Stallman think about the wheel group (from gnu su manual):

Why GNU "su" does not support the `wheel' group ===============================================

(This section is by Richard Stallman.)

Sometimes a few of the users try to hold total power over all the rest. For example, in 1984, a few users at the MIT AI lab decided to seize power by changing the operator password on the Twenex system and keeping it secret from everyone else. (I was able to thwart this coup and give power back to the users by patching the kernel, but I wouldn't know how to do that in Unix.)

However, occasionally the rulers do tell someone. Under the usual "su" mechanism, once someone learns the root password who sympathizes with the ordinary users, he or she can tell the rest. The "wheel group" feature would make this impossible, and thus cement the power of the rulers.

I'm on the side of the masses, not that of the rulers. If you are used to supporting the bosses and sysadmins in whatever they do, you might find this idea strange at first.

Answer 2

login(3) and others do expect primary group. They need it so they can set valid fields in the utmp/wtmp files. And even if they didn't (changed file format), you would hit more fundamental problem when login(1) or sshd(8) or other programs try to setup the user session -- regardless of utmp/wtmp they need to fill both UID and GID kernel process properties (as files created by logged-in user must have UID and GID filled, as you notice).

As for the issue why all-powerful-root needs more than primary group, it doesn't for permission checks (as they're skipped for UID 0), but it does for some other uses.

"wheel" group especially is used for several additional authentication checks like for example pam_wheel

Other groups like "operator" might be used for security features (for example, some process when run by root might setuid(2) to unprivileged USER (like "nobody"), while still retaining its GROUP memberships (like "operator"). It would allow such process to continue to access files owned by that group, while significantly reducing security issues of running with full UID 0 access.

I'm not sure whether there are programs making use of this feature in your system (or if default FreeBSD CURRENT)

Answer 3

It can make a difference - as soon as any program checks group membership and behaves differently depending on the result. Of course, there is no difference to the privileges the root user can force.

Answer 4

Is it not that if no one is a member of group wheel, then wheel is simply ignored and all users can run su ... and potentially guess the password. By having at least one userid a member of group wheel (i.e. userid root), then wheel controls are checked and only other members of group wheel can attempt to run su.

Answer 5

If root in not in group wheel, then it possible to construct an /etc/security/access.conf that prevents public key authentication root login onto a system:

# Make sure root is in group wheel if /etc/security/access.conf 
# contains only these two lines:
+:wheel:ALL
-:ALL:ALL

Worse yet, errors in pam.d configs can make it possible for a wheel user to login, but not be able to sudo to root.