Individual Empowerment

One of the best uses of an undernet is to enable individual team members to contribute. HTML is easy to write, and many word processors and editors will also produce HTML content. All you need now is some way to let all of your users deploy content on your undernet.

You have a lot of choices on how to do this. One way is to give all your users an account on the Linux box. After that, you must ensure that all of your users have rights to the Web directories. The simplest way to do this is to give everyone access to everything. This is fine if the machine is inaccessible to the outside world and you fully trust your network and your employees . If you work with IT professionals, this is a dubious proposition. Still, you can throw it open with the following command (run as root, of course):

 # chmod -R 666 /var/www

A better way would be to create a group, where membership in that group confers the right to modify the Web content. I often create separate groups for access to the HTML content and access to cgi-bin, but we'll keep it simple here.

The sequence to follow to set up a secure group is:

1. Create the group.

2. Change group ownership of the Web directories.

3. Add group read and write permission to the files.

4. Add setgid on the Web directories (optional).

1 Create the Group

Groups are defined in the /etc/group file. The format of entries in this file is:

 GroupName:GroupPassword:GID:MemberList

Field	Description
GroupName	This is the name of the group. Keep this short, preferably eight characters or fewer. This is the name that will show up in long format directory listings and the symbolic name you can use anywhere a group must be specified.
GroupPassword	Just say no! Do not set a group password. It really creates more problems. In theory, an encrypted password here requires the user to enter that password in order to make this group the "primary group." Having a group password allows people who know the password but are not in the MemberList to become group members. I think this just adds complexity and confusion. If you create a group to keep unauthorized users away from certain files, it's a bad idea to give them a potential back door. Users also tend to take shortcuts. If a group member wants to give a nongroup member access to a file belonging to the group, they might be tempted to share the group password. Don't do it. Use MemberList exclusively to control group access.
GID	This is a unique group ID number you create. It must be unique, or you will see confusing things in your file system. (You will set the group ownership of a file to your group name, but you might see some other name when you look. This is because the two different names have the same GID. If it were just an issue of names , it wouldn't be a big deal. It is, however, also a question of security. People in the other named group with the same ID will have access to this file. You probably don't want that. Make sure this number is unqiue.)
MemberList	This is a list of user names that belong to this group. Add a user to this list to give them access to the group's files. Remove a user name from this list to take it away.

So an entry you might make could be:

 undernet:x:5001:mschwarz,pcurtis,smurphy,janderso

2 Change Group Ownership of the Web Directories

You might want to create more than one group. For example, one group would have the ability to modify HTML content, the other might have the ability to write and deploy CGI (common gateway interface) programs. This distinction might be necessary if, for example, you have many people who write documents, only a few of whom are programmers.

For our purposes, our little team is able to do both. So now that we have the groups, we must set the group owner of the Web directories and files to our new group:

 # chgrp -R undernet /var/www

Now the undernet group owns all the files and directories under the Web server.

3 Add Group Read and Write Permission to the Files

In addition to changing the ownership, you must make sure the group can read and write the files that are already there. Generally, I allow the undernet group to read and write everything but the undernet homepage itself. To do this, I issue the following commands:

 # chmod -R g+rw /var/www ; chmod g-w /var/www/htdocs/index.html

The first chmod gives read and write on every file to everyone in the group. The second chmod takes away write permission on the undernet homepage, index.html.

4 Add setgid on the Web Directories (Optional)

Just because someone is a member of a group does not mean that that group is the user's primary group. Every user has a "primary group," that is, the group that will own files the user creates. It defaults to the group specified in the user's /etc/passwd entry. The user may also change it to any group the user belongs to with the newgrp or sg commands.

As we have things now, if a member of the undernet group creates a new file somewhere in the Web server hierarchy, that file will be group owned by whatever group is that user's primary group. That's not what we want. We want the file to be owned by the undernet group automatically so that other undernet users get the correct access to it.

Fortunately, there is a very nice, and little-known , feature of the Unix permissions system that takes care of this for us. Files in Linux can have a setgid attribute. On an executable program, this attribute means that while that program is running, the user belongs to the group owner of the executable program, even if he or she would not normally be in that group. This attribute (and a similar attribute called setuid ) can be used to give the users of a program permissions they would not normally have. This attribute shows up as an "s" in the execute permission spot in a long directory listing, as shown here:

  drwxrwsr-x 7 root wwwadmin 4096 May 31 18:22 htdocs

This bit has a special meaning when it is on a directory instead of an executable file. On a directory, this bit means that files created in this directory should be group owned by the group owner of this directory, no matter what the user's primary group is, so long as the user is a member of the directory's group owner. Read that again if it is confusing. Another way to say it is that if the setgid attribute is set on a directory and a user who is a member of that group creates a file in that directory, that file will be group owned by the group owner of the directory, no matter what the user's primary group is. Phew!

The upshot is that files the get created are group owned by the undernet group, just as we wish.

Since we want only directories to have this attribute, we will use the find command (see Chapter 15 , Tools You Should Know) to apply this permission:

  # find /var/www -type d -exec chmod g+s {} \;

Now all the directories in the Web hierarchy are setgid undernet.