| Creating Groups | ||
|---|---|---|
 | Chapter 13. Administering the Protection Database |  |
| Creating Groups | ||
|---|---|---|
| | Chapter 13. Administering the Protection Database | |
Before you can add members to a group, you must create the group entry itself. The instructions in this section explain how to create both regular and prefix-less groups:
A regular group's name is preceded by a prefix that indicates who owns the group, in the following format:
owner_name:group_name
Any user can create a regular group. Group names must always be typed in full, so a short group_name that indicates the group's purpose or its members' common interest is practical. Groups with names like terry:1 and terry:2 are less useful because their purpose is unclear. For more details on the required format for regular group names, see the instructions in To create groups.
A prefix-less group, as its name suggests, has only one field in its name, equivalent to a regular group's group_name field.
Only members of the system:administrators group can create prefix-less groups. For a discussion of their purpose, see Using Prefix-Less Groups.
By default, the Protection Server assigns the next available AFS GID to a new group entry, and it is best to allow this.
When automatically allocating an AFS GID (which is a negative integer), the Protection Server decrements the max
group id counter by one and assigns the result to the new group. Use the pts
listmax command to display the counter, as described in Displaying and Setting the AFS UID
and GID Counters.
In addition to the name and AFS GID, the Protection Server records the following values in the indicated fields of a new group's entry. See To display a Protection Database entry.
It sets the owner field to the issuer of the pts
creategroup command, or to the user or group specified by the -owner
argument.
It sets the creator field to the username of the user who issued the pts creategroup command.
It sets the membership field to 0 (zero), because
the group currently has no members.
It sets the flags field to S-M--; for explanation,
see Setting the Privacy Flags on Database Entries.
It sets the group quota field to 0, because this
field has no meaning for group entries.
The main reason to create groups is to place them on ACLs, which enables you to control access for multiple users without having to list them individually on the ACL. There are three basic ways to use groups, each suited to a different purpose:
Private use: you create a group and place it on the ACL of directories you own, without necessarily informing the group's members that they belong to it. Members notice only that they can or cannot access the directory in a certain way. You retain sole administrative control over the group, since you are the owner.
The existence of the group and the identity of its members is not necessarily secret. Other users can use the fs listacl command and see the group's name on a directory's ACL, or use the pts membership command to list the groups they themselves belong to. You can set the group's third privacy flag to limit who can use the pts membership command to list the group's membership, but a member of the system:administrators group always can; see Setting the Privacy Flags on Database Entries.
Shared use: you inform the group's members that they belong to the group, but you still remain the sole administrator. For example, the manager of a work group can create a group of all the members in the work group, and encourage them to use it on the ACLs of directories that house information they want to share with other members of the group.
If you place a group owned by someone else on your ACLs, the group's owner can change the group's membership without informing you. Someone new can gain or lose access in a way you did not intend and without your knowledge.
Group use: you create a group and then use the pts chown command to assign ownership to a group, either another group or the group itself (the latter type is a self-owned group). You inform the members of the owning group that they all can administer the owned group.
The main advantage of designating a group as an owner is that it spreads responsibility for administering a group among several people. A single person does not have to perform all administrative tasks, and if the original creator leaves the group, ownership does not have to be transferred.
However, everyone in the owner group can make changes that affect others negatively, such as adding or removing people from the group inappropriately or changing the group's ownership to themselves exclusively. These problems can be particularly sensitive in a self-owned group. Using an owner group works best if all the members know and trust each other; it is probably wise to keep the number of people in an owner group small.
If creating a prefix-less group, verify that you belong to the system:administrators group. If necessary, issue the pts membership command, which is fully described in To display the members of the system:administrators group.
% pts membership system:administrators
Issue the pts creategroup command to create each group. All of the groups have the same owner.
% pts creategroup -name <group name>+ [-owner <owner of the group>]
where
Is an alias for creategroup (and createg is the shortest acceptable abbreviation).
Names each group to create. The name can include up to 63 lowercase letters or numbers, but it is best not to include punctuation characters, especially those that have a special meaning to the shell.
A prefix-less group name cannot include the colon (:), because it is used to separate the two parts of a regular group name:
owner_name:group_name
The Protection Server requires that the owner_name prefix of a regular group name accurately indicate the group's owner. By default, you are recorded as the owner, and the owner_name must be your AFS username. You can include the -owner argument to designate another AFS user, a regular group, or a prefix-less group as the owner, providing the required value in the owner_name field:
If the owner is a user, it must be the AFS username.
If the owner is another regular group, it must match the owning group's owner_name field. For example, if the owner is the group terry:associates, the owner field must be terry.
If the owner is a prefix-less group, it must be the owning group's name.
(For a discussion of why it is useful for a group to own another group, see Using Groups Effectively.)
Is optional and designates an owner other than the issuer of the command. Specify either an AFS username or the name of a regular or prefix-less group that already has at least one member. Do not include this argument if you want to make the group self-owned as described in Using Groups Effectively. For instructions, see To create a self-owned group.
Do not designate a machine as a group's owner. Because a machine cannot authenticate, there is no way for a machine to administer the group.
Issue the pts creategroup command to create a group. Do not include the -owner argument, because you must own a group to reassign ownership. For complete instructions, see To create groups.
% pts creategroup <group name>
Issue the pts adduser command to add one or more members to the group (a group must already have at least one member before owning another group). For complete instructions, see Adding and Removing Group Members.
% pts adduser -user <user name>+ -group <group name>+
Issue the pts chown command to assign group ownership to the group itself. For complete instructions, see To change a group's owner.
% pts chown <group name> <new owner>
Members of the system:administrators group can create prefix-less groups, which are particularly suitable for group use, which is described in Using Groups Effectively.
Suppose, for example, that the manager of the Example Corporation's Accounting Department, user smith, creates a group that includes all of the corporation's accountants and places the group on the ACLs of directories that house departmental records. Using a prefix-less group rather than a regular group is appropriate for the following reasons:
The fact that smith created and owns the group is irrelevant, and a regular group must be called smith:acctg. A prefix-less name like acctg is more appropriate.
If another user (say jones) ever replaces smith as manager of the Accounting Department, jones needs to become the new owner of the group. If the group is a regular one, its owner_name prefix automatically changes to jones, but the change in the owner_name prefix does not propagate to any regular groups owned by the group. Someone must use the pts rename command to change each one's owner_name prefix from smith to jones.
A possible solution is to create an authentication account for a fictional user called acctg and make it the owner of regular groups which have acctg as their owner_name prefix. However, if the acctg account is also used for other purposes, then the number of people who need to know user acctg's password is possibly larger than the number of people who need to administer the groups it owns.
A prefix-less group called acctg solves the problem of inappropriate owner names. The groups that it owns have acctg as their owner_name prefix, which more accurately reflects their purpose than having the manager's name there. Prefix-less groups are also more accountable than dummy authentication accounts. Belonging to the group enables individuals to exercise the permissions granted to the group on ACLs, but users continue to perform tasks under their own names rather than under the dummy username. Even if the group owns itself, only a finite number of people can administer the group entry.
| |  | |
| Creating User and Machine Entries |  | Adding and Removing Group Members |