/etc/group indicates which users are members of which groups. Groups are used for access control; they supplement users.
/etc/group is read at login time.
Each process runs as one user and one or more groups. The login process starts running with all privileges; one the user has successfully authenticated (e.g. by typing a password), the login process takes on the groups indicated in
/etc/group (plus one group indicated in
/etc/passwd) then starts a shell as the authenticated user.
You've probably noticed that each file comes with three sets of permissions (user, group, and other) and an owner and group. When a process tries to access a file, then:
- If the process is running as the user owning the file, the applicable permissions are the user permissions.
- Otherwise, if one of the process's groups is the group owning the file, the applicable permissions are the group permissions.
- Otherwise, the applicable permissions are the other permissions.
$ ls -l myfile
-rw-r----- 1 msh gutenberg 1234 Jul 4 1971 books.txt
msh can read and write this file (
rw-). Any user in the
gutenberg group can read the file (
r--). Other users cannot access the file at all (
Thus groups allow you to make a file accessible to a subset of all users. System services and devices can also be restricted to a certain user or a certain group.
There are three typical uses for groups:
- Groups of physical users working on a common project, accessing the same set of files, as in the example above.
- Groups of physical users for access control to system resources. For example, it's typical for competitive games to store high score files belonging to the user
root and the group
games, writable only by
games and not by all users (
rw-rw----); the game program runs with elevated privileged as the
games group (it is setgid to
games) and so it can read and write the high score files, but other processes cannot.
- Groups of system users. For example, many system services run as a dedicated user and a dedicated group, to minimize the risk that a bug or compromise in one service might affect the others.
Given your symptoms, your system is set up to control access to the
root account via membership in a group. There are several ways to do this. The most common setups are:
- Access to the root account is via sudo. Users must enter their own password to run
sudo. Users are allowed to invoke
sudo to run commands as root if they are in the
admin group. This is indicated by a line like
%admin: ALL=(ALL) ALL in
/etc/sudoers. Sometimes the name of the group is different. This is the default setup in Ubuntu.
- Access to the root account is via su. Only users in the
wheel group may run
su. Users must type the root password to run
su; this way, to infiltrate the root account, an attacker must obtain both a user's password and the root password. This was the default setup on some BSD systems, but it has fallen into disuse as attackers have become more sophisticated (compromise an account, run a keylogger, grab the root password).
Moral: don't change or delete files in
/etc if you don't know what they do. If you do change something, do it from a root shell, and test that you can still log in afterwards; if you can't, revert the change immediately.
I recommend using version control on
/etc. On Ubuntu, install the etckeeper package and run
etckeeper init (as root).