Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm quite new to *nix OS. I understand the format and usage (at least what the man pages says) of the /etc/group file. One day I was trying to replace my group file with a backup copy. I changed the file name to group.old and then all accounts in my machine lost root access. I had to go to single user mode to fix it. It seems I need a in-depth lesson on this group and the whole UNIX account thing.

Can any one give me a link or share your learning experience with me?

share|improve this question

closed as not a real question by rahmu, jasonwryan, uther, Thor, Kevin Feb 12 '13 at 19:57

It's difficult to tell what is being asked here. This question is ambiguous, vague, incomplete, overly broad, or rhetorical and cannot be reasonably answered in its current form. For help clarifying this question so that it can be reopened, visit the help center.If this question can be reworded to fit the rules in the help center, please edit the question.

IMO, this is borderline "not a real question" due to being overly broad, or "not constructive" because of the risk for extended discussion. You may want to narrow the focus to avoid it being closed as such, as well as describe what you have tried. – Michael Kjörling Feb 11 '13 at 8:34
Also, especially if you are new to *nix, the only account on your system which should have root access is root, and you should be using that sparingly if at all. (sudo works well.) Don't fall into the trap of getting used to having root access when it is not explicitly needed; in fact, get used to not having root access. – Michael Kjörling Feb 11 '13 at 8:35
The "question" as it is is not really a question. If you edit it a bit to make it an actual question, perhaps about why what you did broke the system or what the groups file is, I think it stands a good chance of being re-opened. – Kevin Feb 12 '13 at 20:01
up vote 3 down vote accepted

The file /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:

  1. If the process is running as the user owning the file, the applicable permissions are the user permissions.
  2. Otherwise, if one of the process's groups is the group owning the file, the applicable permissions are the group permissions.
  3. Otherwise, the applicable permissions are the other permissions.


$ ls -l myfile
-rw-r-----  1 msh gutenberg 1234 Jul  4  1971 books.txt

The user 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).

share|improve this answer

Perhaps the "Running Linux" book by Dalheimer and Welsh (O'Reilly, 2005) or some of the TLDP guides fits the bill. Your distribution might have some specific guide, look it up. Be specially careful when modifying configuration files. Backing them up is a good idea, but if you change anything better make a copy beforehand (don't move them away). Most distributions have tools to manage users and lots of other configurations, don't consider anything else unless you are absolutely sure you know what you are doing; and when you do know, use them anyway.

share|improve this answer

It is really useful for you to let ppl know what software you are running when you ask questions - in this case it would be useful to know what distro you are running.

Are you by chance running Fedora or Redhat? If so SE Linux might be the problem.

to find out if your running SE Linux run the command: getenforce

It will come back with "enforcing" if you are running SE Linux. If you are running SE Linux then run:

ls -lZ /etc/group.old /etc/group

And compare the difference. If the new file is missing a whole lot of stuff that looks a bit like this:


in the listing that the old file has, you probably lost your SElinux context info.

You can copy the SElinux context from the old file with:

chcon --reference /etc/group.old /etc/group

Probably the sensible answer if you are just learning is turn off SE Linux. You can do that with:

setenforce 0

That will kill SELinuc untul you reboot (or run setenforce 1).

To turn SElinux off permantly you'll need to edit:

share|improve this answer
What makes you so sure the OP is running Linux? :) – Michael Kjörling Feb 11 '13 at 13:09
Nothing. Which is why I qualify my response with: "Are you by chance running Fedora or Redhat? If so SE Linux might be the problem." But chances are these days a newbie unix user is gonna be using Linux - but I did consider the scenario they might not be or even if they were were not running an SELinux enabled distro and qualified accordingly. I've been a pedant for a long time now. :-) – Jason Tan Feb 11 '13 at 13:19
Few UNIX-like systems other than Linux really come in terms of "distros". – Michael Kjörling Feb 11 '13 at 13:22
BSDs (that's Berkeley Systems DISTRIBUTION) do. Net, Free, Open, etc. But if it makes you feel better I am happy to concede that I could have worded my response better and I did. And for the reasons above - I did assume that on the balance of probabilities that the OP probably was using a Linux. I wasn't sure - but I did think it likely that the OP was a linux user. Feel better? Vonbrand appears to have made the same assumption. And hasn't even made a token qualifcation/disclaimer. Sic him! – Jason Tan Feb 11 '13 at 13:32

Not the answer you're looking for? Browse other questions tagged or ask your own question.