[ Team LiB ] Previous Section Next Section

Setting Up and Administering Groups

graphics/new.gif

The group database (NIS maps, NIS+ tables, LDAP Directory Information Tree (DIT) entries, or local /etc/group file) stores information about user groups, traditionally called UNIX groups. A user group is a collection of users who can share files and other system resources. For example, a set of users who are working on the same project could be formed into a user group.

Each group has a group ID (GID) that identifies it internally to the system. A group should have a name and a list of user names. User groups can be defined in two ways.

  • Implicitly, by the GID for the user's primary group, which is defined in the user account. Whenever a new GID appears in the relevant field of a nameservice database, a new group is defined.

  • Explicitly, by name, GID, and user list.

NOTE. It's best to explicitly define all groups so that every group has a name.


All users belong to at least one group—their primary group—which is indicated by the Group field of their user account. Although it is not required by the operating system, you should add the user to the member list of the group you've designated as his or her primary group. Optionally, users can belong to up to 16 secondary groups. To belong to a secondary group, the user must be added to the group's member list.

The groups command shows the groups to which a user belongs. In the following example, the user belongs to the staff group.

graphics/new.gif

mopoke% groups
staff
mopoke%

graphics/new.gif

You can use the id -a command to display more information about a user account, including the group name and GID, as shown in the following example.


mopoke% id -a
uid=1001(winsor) gid=10(staff) groups=10(staff)
mopoke%

For any user, only one group at a time can be considered the primary group. However, users can temporarily change the primary group (with the newgrp command) to any other group they belong to.

graphics/new.gif

Some applications look at the user's primary group only. For example, ownership of files created and accounting data recorded reflect only the primary group. Other applications may take into account a user's membership across groups. For example, when using Admintool (which has been replaced by the SMC tools) a user had to be a member of the sysadmin group to make changes to a database, but it didn't matter if sysadmin was the current primary group or a secondary group.

User groups are probably best known as the groups referred to by the read-write-execute permissions for the user, group, and other on files and directories. These permissions are a cornerstone of security. You cannot access others' files (if they do not allow world access) unless your primary or a secondary group has permission to access the files. For example, a group called techwrite could be created for technical writers, and a central directory of document files could be set up with write permission for the techwrite group. That way, only writers would be able to change the files.

User groups can be local to a workstation or used across a network. Across the network, user groups allow a set of users on the network to access a set of files on a workstation or file server without making those files available to everyone.

NOTE. NIS+ supports another, unrelated, kind of group, called an NIS+ group, which assigns access rights to NIS+ objects. These groups have nothing to do with using NIS+ to maintain a database of user groups.


graphics/new.gif

You can use the SMC System Configuration/Users/Groups tool to create and administer groups. By default, SMC manages accounts on the local system. You can create a nameservice domain toolbox to manage accounts in the LDAP, DNS, NIS+, or NIS nameservices. Refer to the Solaris Management Console Tools book for instructions.

Setting Up Fields in the Group Database

The Group database (NIS maps, NIS+ tables, LDAP DIT entries, or local /etc/group file) has the following fields.

  • Group Name.

  • Group ID.

  • User (Member) List.

An additional Group Password field is rarely used. The Group Password field is a relic of earlier versions of UNIX. It is usually left empty or filled with an asterisk. If a group has a password, the newgrp command prompts users to enter it. However, there is no command to set the password.

Setting Up a Group Name Field

The Group Name field contains the name assigned to the group. For example, members of the chemistry department in a university may be called chem. Group names can have a maximum of nine characters.

Setting Up a Group ID Field

The Group ID field contains the group's numerical ID. It must be unique from all other group IDs on a system and should be unique across the entire organization. You can assign GIDs as a whole number between 100 and 60000. Numbers 60001 and 60002 are assigned to nobody and noaccess, respectively, and numbers under 100 are reserved for system default group accounts.

graphics/new.gif

Starting with the Solaris 2.5.1 release, you can also assign GID numbers between 6003 and 2147483647. If you use GID numbers in this range, refer to Table 34 on page 147 and Table 35 on page 148 for information about interoperability issues and limitations on large GID numbers.

When you use the SMC Users tool to add user accounts, the default group is staff. You can choose another primary group from the menu. For security reasons, do not set the primary group as root with a GID of 0.

Setting Up a User (Member) List Field

The User List field contains a list of the users in the group. User names are separated by commas. These names must be the official login names defined in the password nameservice database or the local /etc/passwd file if no nameservice is used. As already noted, each user can belong to a maximum of 17 groups.

Identifying Default UNIX User Groups

By default, all Solaris workstations and servers have the following groups.


root::0:root
other::1:
bin::2:root,bin,daemon
sys::3:root,bin,sys,adm
adm::4:root,adm,daemon
uucp::5:root,uucp
mail::6:root
tty::7:root,tty,adm
lp::8:root,lp,adm
nuucp::9:root,nuucp
staff::10:
daemon::12:root,daemon
sysadmin::14:
nobody::60001:
noaccess::60002:
nogroup::65534

NOTE. The sysadmin group with a GID of 14 is part of the default set of groups.


Creating New Groups

As a system administrator, you frequently may create new group accounts. You must create a group and assign it a GID before you can assign users to it.

graphics/new.gif

Use SMC to create and maintain local groups. You must have root access or the appropriate rights to be able to administer the /etc/group file. By default, SMC manages accounts on the local system. You can create a nameservice domain toolbox to manage group accounts in the LDAP, DNS, NIS+, or NIS nameservices. Refer to the Solaris Management Console Tools book for instructions.

You need the following information to create a new group.

  • Login names of users who will belong to the group.

  • Group name.

  • GID.

Modifying Groups

Membership in group accounts can change frequently as new employees are hired and other employees change job responsibilities. Consequently, you will modify existing group accounts to add or remove users. If you choose to have a user belong to secondary groups, you must modify those groups to add the user to the user lists. When adding groups, you may make a mistake. The ability to modify or delete groups helps you correct such mistakes.

If a group account is no longer needed, you can delete user accounts from it.

Deleting User Accounts

Use the following checklist for deleting a user account.

  • Delete the user's entry from the NIS+ Passwd database, NIS map, or /etc/passwd files.

  • Remove the user's name from entries in the NIS+ Group database, NIS map, or /etc/group files. If a group is no longer needed, you can delete user accounts from it.

  • Remove the user from any printer access or deny lists.

  • Decide whether to delete or archive all of the user's files and do so.

  • Delete the user's mail file.

  • Remove the user from any aliases.

    [ Team LiB ] Previous Section Next Section