Assigning Users to Groups

After defining all user - related information, you need to consider groups. Groups are often overlooked in the HP-UX environment until the system administrator finds that all his or her users are in the very same group , even though from an organizational standpoint, they are in different groups. Before I cover the groups in general, let's look at a file belonging to a user and the way access is defined for a file:

 $  ll  -rwxr-x--x   1 marty     users     120 Jul 26 10:20 sort 

For every file on the system, HP-UX supports three classes of access:

• User access (u) . Access is granted to the owner of the file

• Group access (g) . Access is granted to members of the same group as the owner of the file

• Other access (o) . Access is granted to everyone else

These access rights are defined by the position of r (read), write (w), and execute (x) when the long listing command is issued. For the long listing ( ll ) above, you see the permissions in Table 8-1.

Table 8-1. Long Listing Permissions

Access	User Access	Group Access	Other
Read	r	r	-
Write	w	-	-
Execute	x	x	x

You can see that access rights are arranged in groups of three. Three groups of permissions exist with three access levels each. The owner, in this case, marty, is allowed read, write, and execute permissions on the file. Anyone in the group users is permitted read and execute access to the file. Others are permitted only execute access to the file.

These permissions are important to consider as you arrange your users into groups. If several users require access to the same files, then you will want to put those users in the same group. The trade-off here is that you can give all users within a group rwx access to files, but then you run the risk of several users editing a file without other users knowing it, thereby causing confusion. On the other hand, you can make several copies of a file so that each user has his or her personal copy, but then you have multiple versions of a file. If possible, assign users to groups based on their work.

The /etc/group file contains the group name , an encrypted password (which is rarely used), a group ID, and a list of users in the group. Here is an example of an /etc/group file:

 root::0:root other::1:root, hpdb bin::2:root,bin sys::3:root,uucp adm::4:root,adm daemon::5:root,daemon mail::6:root lp::7:root,lp tty::10: nuucp::11:nuucp military::25:jhunt,tdolan,vdallesandro commercial::30:ccascone,jperwinc,devers nogroup:*:-2: 

This /etc/group file shows two different groups of users. Although all users run the same application, a desktop publishing tool, some work on documents of "commercial" products while others work on only "military" documents. It made sense for the system administrator to create two groups, one for commercial document preparation and the other for military document preparation. All members of a group know what documents are current and respect one another's work and its importance. You will have few problems among group members who know what the other members are doing and you will find that these members don't delete files that shouldn't be deleted. If you put all users into one group, however, you may find that you spend more time restoring files, because users in this broader group don't find files that are owned by other members of their group to be important. Users can change group with the newgrp command.