Certification Objective 6.05-Creating and Maintaining Special Groups

One major difference between Red Hat Enterprise Linux and non-Red Hat Linux or Unix distributions is how new users are assigned to groups. A Linux group allows its members to share files. Unfortunately, that also means everyone in the same primary group has access to the home directories of all other group members. Users may not always want to share the files in their home directories with others. For example, if you're setting up an ISP, your users pay for their privacy.

On the other hand, RHEL gives each user a unique user ID and group ID in /etc/ passwd. This is known as the user private group scheme. Users get exclusive access to their own groups and don't have to worry about other users reading the files in their home directories.

On the Job 

There are other ways to provide access to other users, as discussed in Chapter 4's "Access Control Lists."

Standard and Red Hat Groups

Traditionally, users are assigned to one or more groups such as users in /etc/group. For example, you might configure accgrp for the accounting department and infosys for the information systems department in your company.

If you have access to one of these other versions of Unix or Linux, check the third and fourth fields in /etc/passwd. Many users will have the same fourth field, which represents their primary group. Then, when you create a new user, each account receives a unique user ID but shares the same group ID with other users in the acct group. Users can also belong to other groups.

In RHEL, each user gets her own special private group by default. As you probably noticed earlier, user IDs and group IDs by default start at 500, match, and proceed in ascending order.

By default in RHEL, all regular users have a umask of 0002. If you are coming from a traditional Unix environment, you may be concerned. With the traditional user/group scheme, any member of that user's primary group will automatically have write access to any file that the user creates in his home directory.

This is the advantage behind the user private group scheme. Since every user account is the only member in its own private group, having the umask set to 0002 does not affect file security. This provides advantages for systems such as ISPs, where you don't want users to have access to each other's files.

Shared Directories

Most people work in groups. They may share files. You can give a group of users access to a specific user's home directory or you can set up a shared directory for a group.

When you configure a shared directory, you can set up a group owner and then add the users to that group through the /etc/group configuration file. When you set the group ID bit (SGID) on this directory, any file created in this directory inherits the group ID. Assuming you have set appropriate permissions, all members of this group can then access files in that directory.

There are several basic steps required to create a useful shared directory. For example, assume you want to set up a shared directory, /home/accshared, for the accountants in your organization. To set this up, take the following steps:

1. Create the shared directory:

    # mkdir /home/accshared 

2. Create a group with the users in your accounting department. Give it a group ID that doesn't interfere with existing group or user IDs. One way to do this is to add a line such as the following to your /etc/group file. You could also create this kind of group using the Red Hat User Manager. Note that the name of this new group is accgrp. Substitute the usernames of your choice.

    accgrp:x:5000:robertc,alanm,victorb,roberta,alano,charliew 

3. Set up appropriate ownership for the new shared directory. The following commands prevent any specific user from taking control of the directory and assign group ownership to accgrp:

    # chown nobody.accgrp /home/accshared # chmod 2770 /home/accshared 

Any user who is a member of the accgrp group can now create files in the /home/ accshared directory. Any files generated within that directory will then be associated with the accgrp group ID, and all users listed as members of accgrp in the /etc/group file will have read, write, and execute access to the /home/accshared directory.

What makes this possible are the permissions that you've assigned to the /home/ accshared directory: 2770. Let's break this down into its component parts.

The first digit (2) is the set group ID bit, also known as the SGID bit. When you set the SGID bit for a directory, any files created in that directory automatically have their group ownership set to be the same as the group owner of the directory. There are two ways to set the SGID bit for the /home/accshared directory:

 chmod g+s /home/accshared 

or alternatively, the following command sets the SGID bit and sets appropriate permissions for a shared directory:

 chmod 2770 /home/accshared 

Setting the SGID bit solves the problem of making sure all files created in a shared directory belong to the correct group-as long as the umask is set properly.

The remaining digits are basic knowledge for any experienced Linux or Unix user. The 770 sets read, write, and execute permissions for the user and group that own the directory. But since the user owner is nobody, the group owner is what counts. In other words, members of the accgrp group gain read, write, and execute permissions to files created in this directory.

Otherwise, users who are members of accgrp and belong to another primary group would have to remember to use the chgrp command on every file they put in /home/ accshared. While clumsy, that command allows other users in that group to access the file.

Exercise 6-4: Controlling Group Ownership with the SGID Bit

In this exercise, you will create new files in a directory where the SGID bit is set.

1. Add users called test1, test2, and test3. Specify passwords when prompted. Check the /etc/passwd and /etc/group files to verify that each user's private group was created:

    # useradd test1; passwd test1 # useradd test2; passwd test2 # useradd test3; passwd test3 

2. Edit the /etc/group file and add a group called tg1. Make the test1 and test2 accounts a member of this group. You could add the following line to /etc/ group directly or use the Red Hat User Manager:

    tg1:x:9999:test1,test2 

   Before you proceed, make sure the group ID you assign to group tg1 (in this case, 9999) is not already in use.

3. Create a shared directory for the tg1 group:

    # mkdir  /home/testshared 

4. Change the user and group ownership of the shared directory:

    # chown  nobody.tg1  /home/testshared 

5. Log in as test1 and test2 separately. Change the directory to the testshared directory and try to create a file. Two ways to do so are with the following commands. What happens?

    $ date  >>test.txt $ touch abcd 

6. Now as the root user, set group write permissions on the testshared directory.

    # chmod 770 /home/testshared 

7. Log in again as user test1, and then try to create a file in the new directory. So far, so good.

    $ cd /home/testshared $ date  >> test.txt $ ls -l test.txt 

8. Now check the ownership on the new file. Do you think other users in the tg1 group can access this file?

    $ ls -l 

9. From the root account, set the SGID bit on the directory:

    # chmod g+s  /home/testshared 

   (Yes, the efficient among you may know that the chmod 2770 /home/testshared command combines steps 6 and 9.)

10. Switch back to the test1 account and create another file. Check the ownership on this file. Do you think that user test2 can now access this file? (To see for yourself, try it from the test2 account.)

     $ date >> testb.txt $ ls  -l 

11. Now log in as the test2 account. Go into the /home/testshared directory, create a different file, and use ls -l to check permissions and ownership again. (To see that it worked, try accessing this file from the test1 account.)

12. Switch to the test3 account and check whether you can or cannot create files in this directory, and whether you can or cannot view the files in this directory.