Using Groups to Eliminate Root

by Michael W. Lucas
08/15/2002

The root password can be a cause of contention in any organization. Many system administrators hate giving it out, even to people who are responsible for maintaining part of the system. If this sort of system administrator doesn't know how to properly manage things, this reluctance can keep people from being able to do their jobs. Many other system administrators hand out root to dang near anyone who wants to use it, and then complain when the system becomes unstable. Unix has powerful facilities for removing the need to use the root password. In the next few articles, we're going to consider minimizing use of the root password. This article discusses using groups as an alternative.

One common situation is where a junior administrator is responsible for a particular portion of the system. I've had many DNS administrators work for me; these people don't ever install software, recompile the kernel, or do other low-level system tasks. They just answer email, update the zone files on the nameservers, and reload named. New junior administrators frequently seem to think that they need root to do this sort of work. With proper use of groups, and a bit of scheduling, you don't need to hand out root at all! In this article, we're going to implement group-based security for managing DNS files. The same techniques can be applied to almost any other section of the system.

Unix classifies users into groups, each group consisting of people who perform similar administrative functions. You can have a group called Web, which includes the people who edit Web pages, and a group called dns that includes the people who manage your nameserver. Depending on your operating system, you might already have groups with similar names. For example, NetBSD and OpenBSD both include a user and a group named, while FreeBSD has a user and group called bind, all for use by the nameserver. These predefined users and groups are generally used by programs on the system. Web servers generally run as the www user, for example.

Related Reading Essential System Administration Tools and Techniques for Linux and Unix Administration By Æleen Frisch

For our purposes, we'll want to define a separate group for users who need access to files used by these programs. We don't need a matching user account, however. Group information is in /etc/group. Each line in /etc/group contains four colon-delimited fields.

The first is the group name. Group names are fairly arbitrary: you could give your DNS managers the group name "losers" if you wished. It's a good idea, however, to choose group names that give you some idea of what they're for; while you might remember that the group xyzzy manages your email system today, will you remember it six months from now? Choose group names that mean something.

The second field contains the group's encrypted password. Group passwords encouraged poor security practices, so most modern Unixes don't support them. As with many other things in Unix, however, this field has always been there and so we're stuck with it. Rather than leave this field blank, we use an asterisk (*) as a placeholder.

The third field holds the group's unique numeric ID (GID). Many of FreeBSD's internal programs use this GID, rather than names, to identify groups. /etc/groups is sorted in order by GID.

Last is a list of all the users in that group. To add a user to a group, simply add the username to this list, separated from other names with commas.

To create a group, you just need to pick a unique group ID number. You'll want to pick a number that isn't likely to be taken by a user or some other program. For groups like the dns group we're creating, which are closely related to another group in the system, I'll frequently pick a GID that's off by one from its related group. For example, on FreeBSD the bind user has a GID of 53 (from the network port number nameservers use). Our new dns group will have a GID of 54. I want to add the local users "chris", "phil", and "michael" to this group, so our new entry will look like this.

dns:*:54:chris,phil,michael

After editing /etc/group, it's a good idea to make sure you haven't made a mistake. FreeBSD includes chkgrp(8), which checks the syntax of the groups file; if it runs silently, you haven't shot yourself in the foot.

Now that you have a group, you can use it to assign ownership of files. Every file is owned by both a user and a group. You can see the existing ownership of a file with ls -l. Many new system administrators pay close attention to the owner, and to the word permissions, but gloss over the group permissions.

# ls -l
total 29
-rw-------  1 root  wheel   27136 Sep 14 09:36 file1
-rwxrwxr--  1 root  wheel    1188 Sep 14 09:35 file2
#

Here, file1 can only be read or written to by root. file2 can be read by root or any member of the group wheel. If you're in the wheel group, you don't need to become root to edit or read file2 file; you can just open your text editor and go!

Also in Big Scary Daemons: Running Commercial Linux Software on FreeBSD Building Detailed Network Reports with Netflow Visualizing Network Traffic with Netflow and FlowScan Monitoring Network Traffic with Netflow Information Security with Colin Percival

To change a group owner on a file, use chgrp(1).

# chgrp groupname filename

Now, in BSD wheel is a system group. Wheel is the group of users who may use the root password. You don't want to go generically making files writable by wheel; this would strongly violate the principle of least privilege. Similarly, bind is a group used by the nameserver program. You don't want the nameserver program to be able to write DNS zone files; if someone compromises the nameserver, then the nameserver would be able to write files directly to the disk. This would be bad. But consider the following permissions scheme on the zone file for blackhelicopters.org:

-rw-rw-r--  1  mwlucas   dns   486 Jun  7 10:14 blackhelicopters.org.db

This file is owned by me, as the senior administrator, but it's writeable by anyone in the dns group. (You could also set up a particular user to own these files.) Anyone in the dns group can read and write to this file, without using the root password. Finally, this file can be read by the nameserver.

The only thing the DNS administrators need the root password for now is to restart the nameserver. This is easily dealt with by setting up a cron job to reload the nameserver. These administrators still might want to reload the nameserver manually on occasion, however. We'll look at allowing them to do so without using the root password in the next article.

Michael W. Lucas

---

Read more Big Scary Daemons columns.

Return to the BSD DevCenter.