Section 10.1. The Boss Wants to Set Up a Special Group of Users | Linux Annoyances for Geeks: Getting the Most Flexible System in the World Just the Way You Want It

10.1. The Boss Wants to Set Up a Special Group of Users

When the boss wants to set up a group for a special set of users, such as managers or accountants, you need to know how to create the group, along with a directory accessible only to the user members of that group.

To understand what you need to do, it helps to know the baseline user and group settings on various Linux distributions. Then you'll know exactly what you need to do to create a special group on your systems.

Linux distributions classify users in different ways. Most distributions configure regular users as members of a single "Users" group. In contrast, Red Hat/Fedora configures users in their own exclusive groups, in the so-called "User Private Group" scheme. The permissions on each user's Red Hat/Fedora home directory keep users from reading files in other users' home directories.

What's best? It depends. In some organizations, it can be helpful to allow users to read one another's files. If you're running an ISP, you don't want that. The Red Hat/Fedora scheme can help you keep user files private.

It's not difficult to convert between the Red Hat/Fedora User Private Group scheme and the standard Linux scheme. All you need to do to convert to the Red Hat scheme is change the file creation mask so that each user's private group has read (and perhaps even write) access, modify user membership in groups, and change permissions on user home directories.

This annoyance assumes you have a single database of users and groups on your network. That database might be on a Network Information System (NIS) server, as defined in http://www.tldp.org/HOWTO/NIS-HOWTO; it could be a part of a Lightweight Directory Access Protocol (LDAP) server, as defined in the book LDAP System Administration by Gerald Carter (O'Reilly); it could even be a part of a Microsoft user database and accessed through Samba (see Using Samba by Jay Ts et al., also published by O'Reilly).

For the purpose of this annoyance, I'm assuming that the database works through standard authentication schemes on one Linux computer, as configured in files such as /etc/passwd and /etc/group, and with defaults in /etc/default/useradd and /etc/login.defs.

Now I'll define how user schemes work on standard and Red Hat/Fedora Linux distributions. Then I can show you how to create a special group on any Linux distribution.

10.1.1. The Standard User Scheme

Linux distributions normally configure all users in the same group. In other words, all users are assigned the same Group ID (GID), which happens to be 100.

You can confirm group memberships, also known as GIDs, in /etc/passwd and /etc/group. They are defined in the fourth column in /etc/passwd. As an example, I've taken the following excerpt from one of my /etc/passwd files. Users michael and editor both belong to the same group, with a GID of 100:

 michael:x:1000:100:author,,,:/home/michael:/bin/bash editor:x:1001:100:editor,,,:/home/editor:/bin/bash

You may recall that permissions for files and directories are classified by owner, group, and others. While this provides the opportunity to help users share their files, that is not enough. By default on our distributions, users have only read access on the files of other users in the same group. For example, when I create laforgeeks-ch10.sxw on my home directory, it has the following permissions, as defined by an ls -l command:

 -rw-r--r--  1 michael users   40800 2005-09-28 18:07 laforgeeks-ch10.sxw

In other words, even if user editor is also a member of the users group, she can only read the noted file. To allow the editor to make changes to that file, the owner would have to change the permissions.

A user who wants to allow others to write to his files has to modify the associated permissions. Fortunately, the owner has the right to change the permissions on his own files with a command such as:

 chmod 664 laforgeeks-ch10.sxw

Few regular users understand the chmod command. But users can change permissions in GUI file browsers such as Nautilus and Konqueror. All they need to do is right-click on the desired file, select Properties from the pop-up menu, and change group permissions so the group can write to the file.

Unfortunately, this method makes the file writable to everybody in the general-users groupeveryone with a regular account on that system. You may not want to let everyone write to your files. To address these issues, I'll describe a special group scheme and procedures later in this annoyance.

You may also want to configure limits on how much disk space can be occupied by a particular group. You can do this with group-based quotas, as defined in the "Some User Is Taking Too Much Disk Space" annoyance later in this chapter.

10.1.2. The Red Hat User Private Group Scheme

Red Hat/Fedora configures users differently from most Linux distributions. Every time a new user is created on a Red Hat system, he's assigned as the only member of his own private group. For example, on my Red Hat Enterprise Linux 4 computer, I have the following entries:

 donna:x:501:501::/home/donna:/bin/bash nancy:x:502:502::/home/nancy:/bin/bash

The third and fourth columns specify the user and group IDs. As you can see, the user and group IDs are the same for each user. In other words, both donna and nancy are members of their own special groups.

In addition, you'll find that the permissions are limited on home directories on Red Hat/Fedora distributions; for example, when I run the ls -l /home command, I get the following output:

 drwx------   3 donna   donna   4096 Jul  5 16:41 donna drwx------  38 michael michael 4096 Sep 29 10:38 michael drwx------   2 nancy   nancy   4096 Jul 22 18:18 nancy drwx------   4 randy   randy   4096 Jul 22 17:57 randy

In other words, read, write, and execute permissions on user home directories are limited to that user. As a consequence, when I log in as user michael and try to list the contents of user nancy's home directory, I get the following message:

 ls: /home/nancy: Permission denied

In contrast, if you examine the permissions on SUSE or Debian-based home directories, you'll find that permissions aren't so limited, and users can read the contents of other users' home directories.

While the Red Hat User Private Group scheme does help keep user files secure, it does not encourage collaboration. When there's a need for any shared work, you'll have to take some special steps, but these are different from the steps necessary on other Linux distributions.

10.1.3. Configuring a Special Group

There are many reasons why you might configure a special group. Accountants may want to share their files with one another but keep their files secure from regular users. Supervisors may want to keep employee evaluations confidential. Team members on a special project may need to share information without interference from other employees. Whatever the reason, configuring a special group requires:

Creating the new group, specifying the desired list of users
Creating a special directory for the members of the group, with appropriate ownership and the Group ID bit
Making sure the files that are copied to the special directory are writable by members of the groupand only by them

As an example, I'll illustrate how you can set up a special group for users who want to share their secrets in wine making. I'll call the group winos and make users napa, sonoma, willamette, and columbia part of this group. To do so, I take the following steps:

Add the specified users, if they don't already exist. While each of our distributions includes GUI tools, the command-line method employs the useradd -m command, which makes sure to create the appropriate home directory, with default files as specified in the /etc/skel directory.
```
 useradd -m napa 
```
Assign passwords if these are new accounts, with commands such as passwd napa.
Create the winos group, and specify an appropriate GID. The second task is tricky because automated tools that create accounts assign IDs of their own, and it's important not to let the IDs overlap with yours. In addition to the useradd and adduser commands, IDs are generated when a Linux system, through the idmap uid and idmap gid directives in a Samba configuration file, takes accounts from a Microsoft-style Domain Controller database, which by default takes user and group ID numbers of 1000020000. If you choose a high GID, such as 30000, you can be confident it will lie outside the range of these automatically generated IDs. (With Linux kernel 2.6, the maximum number of users has been increased from 65,000 to over 4 billion.)
```
 groupadd -g 30000 winos 
```
Now add the desired users to the group you just created. You can do so by opening up /etc/group in a text editor and adding the desired users to the end of the winos group directive (don't include any spaces in the directive):
```
 winos:x:30000:napa,sonoma,willamette,columbia 
```
For distributions that support shadow groups, make sure the new group memberships are reflected in /etc/gshadow with the following command:
```
 grpconv 
```
Red Hat/Fedora and Debian Linux support shadow groups and have an /etc/gshadow file; as SUSE Linux does not, the grpconv command leads to an error message.
Create the shared directory for these special users:
```
 mkdir /home/winos 
```
Assign appropriate ownership to this directory; the owner should be either the administrative user (root) or another user no cracker can log in as, such as nobody. Assign group ownership to the group you created:
```
 chown nobody /home/winos chgrp winos /home/winos 
```
You can also combine these commands:
```
 chown nobody.winos /home/winos 
```
Assign appropriate permissions to this directory; most of the time you want to limit permissions to members of the winos group, which you can do by running the following command:
```
 chmod 070 /home/winos 
```
Set the SGID bit on this directory. This is critical. It allows all members of the winos group to read, write, and execute all files copied to /home/winos by other users in the special group:
```
 chmod g+s /home/winos 
```
Naturally, you can combine steps 7 and 8 with the chmod 2070 /home/winos command.
On distributions other than Red Hat/Fedora, your users will have to change permissions to the files that they want to share. They can do so by right-clicking the file in Nautilus or Konqueror and clicking Properties from the pop-up menu. This opens a Properties window for the file, where they can enable read and write permissions on the file for the group under the Permissions tab.
Alternatively, you could configure other distributions with a Red Hat-style User Private Group scheme, with the same value for umask (0002) and the same configurations in /etc/default/useradd and /etc/login.defs before creating the users associated with the special group.
Now test the result. Log in as one of the users in the special group.
Create a file. In this case, I've started OpenOffice.org Writer and saved some instructions to the winemaking.sxw file.
Copy the file that you want to share to the common directory:
```
 cp winemaking.sxw /home/winos 
```
On distributions other than Red Hat/Fedora, make sure the permissions support group writing by modifying the aforementioned properties in Nautilus or Konqueror (see step 9), or with a command such as:
```
 chmod g+w /home/winos/winemaking.sxw 
```
On Red Hat/Fedora distributions, this is not necessary, as the default umask is 0002, which supports group write permissions.
Log in as a different user in the special group. Open the file in OpenOffice.org Writer. Make changes and save the file, making sure you save it to the shared directory.

Now you can provide instructions to users in your special group on how they can share and access files in the directory that you've created.

If multiple users are adding information to a shared file simultaneously, it's important that they open the file from the shared directory, using the same application. When one user has opened this file, Linux applications create a temporary, hidden "lock file" that prevents other users from writing to the file. Other users can still open the file with read-only settings. You'll need to inform your users that a read-only message means someone else has opened that file, and that they should wait until the other person closes the file.

But before you let your users open shared files, test them with the applications that they'll use. Make sure the lock mechanism works. Log in as two different users in your special group. Open a file in the shared directory. If the lock mechanism works, the second user that opens the file gets read-only access.

Unfortunately, file locking is disabled in the OpenOffice.org 1.x suite. As of this writing, it doesn't work for the OpenOffice.org 2.0.x suite. A fix is scheduled for OpenOffice.org 2.0.3, which is scheduled to be released about the time this book reaches the shelves. For more information, see OpenOffice.org bug 57712.