Michael W. Lucas
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
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
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
all for use by the nameserver. These predefined users and groups are
generally used by programs on the system. Web servers generally run
www user, for example.
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
/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
/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.
/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
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 #
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:
To change a group owner on a file, use
# 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.
Read more Big Scary Daemons columns.
Return to the BSD DevCenter.