# Administering the Protection Database

This chapter explains how to create and maintain user, machine, and group entries in the Protection Database.

## Summary of Instructions

This chapter explains how to perform the following tasks by using the indicated commands:

Display Protection Database entry | pts examine
Map user, machine or group name to AFS ID | pts examine
Display entry's owner or creator | pts examine
Display number of users or machines belonging to group | pts examine
Display number of groups user or machine belongs to | pts examine
Display group-creation quota | pts examine
Display entry's privacy flags | pts examine
Display members of group, or groups that user or machine belongs to | pts membership
Display groups that user or group owns | pts listowned
Display all entries in Protection Database | pts listentries
Create machine entry | pts createuser
Create group entry | pts creategroup
Add users and machines to groups | pts adduser
Remove users and machines from groups | pts removeuser
Delete machine or group entry | pts delete
Change a group's owner | pts chown
Change an entry's name | pts rename
Set group creation quota | pts setfields
Set entry's privacy flags | pts setfields
Display AFS ID counters | pts listmax
Set AFS ID counters | pts setmax

## About the Protection Database

The Protection Database stores information about AFS users, client machines, and groups which the File Server process uses to determine whether clients are authorized to access AFS data.

To obtain authenticated access to an AFS cell, a user must have an entry in the cell's Protection Database. The first time that a user requests access to the data stored on a file server machine, the File Server on that machine contacts the Protection Server to request the user's current protection subgroup (CPS), which lists all the groups to which the user belongs. The File Server scans the access control list (ACL) of the directory that houses the data, looking for groups on the CPS. It grants access in accordance with the permissions that the ACL extends to those groups or to the user individually. (The File Server stores the CPS and uses it as long as the user has the same tokens. When a user's group membership changes, he or she must reauthenticate for the File Server to recognize the change.)

Only administrators who belong to the cell's system:administrators group can create user entries (the group is itself defined in the Protection Database, as discussed in The System Groups). Members of the system:administrators group can also create machine entries, which can then be used to control access based on the machine from which the access request originates. After creating a machine entry, add it to a Protection Database group and place the group on ACLs (a machine cannot appear on ACLs directly). A machine entry can represent a single machine or multiple machines with consecutive IP addresses as specified by a wildcard notation. For instructions, see Creating User and Machine Entries. Because all replicas of a volume share the same ACL (the one on the volume's root directory mount point), machine entries enable you to replicate the volume that houses a program's binary file while still complying with a machine-based license agreement as required by the program's manufacturer. See Creating User and Machine Entries.

A group entry is a list of user entries, machine entries, or both (groups cannot belong to other groups). Putting a group on an ACL is a convenient way to extend or deny access to a set of users without listing them on the ACL individually. Similarly, adding users to a group automatically grants them access to all files and directories for which the associated ACL lists that group. Both administrators and regular users can create groups.

### The System Groups

In addition to the groups that users and administrators can create, AFS defines the following three system groups. The Protection Server creates them automatically when it builds the first version of a cell's Protection Database, and always assigns them the same AFS GIDs.

system:anyuser

  Represents all users able to access the cell's filespace from the local and foreign cells, authenticated or not. Its AFS GID is -101. The group has no stable membership listed in the Protection Database. Accordingly, the pts examine command displays 0 in its `membership` field, and the pts membership command does not list any members for it.

  Placing this group on an ACL is a convenient way to extend access to all users. The File Server automatically places this group on the CPS of any user who requests access to data stored on a file server machine. (Every unauthenticated user is assigned the identity anonymous and this group is the only entry on the CPS for anonymous.)

system:authuser

  Represents all users who are able to access the cell's filespace from the local and foreign cells and who have successfully obtained an AFS token in the local cell (are authenticated). Its AFS GID is -102. Like the system:anyuser group, it has no stable membership listed in the Protection Database. Accordingly, the pts examine command displays 0 in its `membership` field, and the pts membership command does not list any members for it.

  Placing this group on an ACL is therefore a convenient way to extend access to all authenticated users. The File Server automatically places this group on the CPS of any authenticated user who requests access to data stored on a file server machine.

system:administrators

  Represents the small number of cell administrators authorized to issue privileged pts commands and the fs commands that set quota. The ACL on the root directory of every newly created volume grants all permissions to the group. Even if you remove that entry, the group implicitly retains the a (administer), and by default also the l (lookup), permission on every ACL. Its AFS GID is -204. For instructions on administering this group, see Administering the system:administrators Group.

## Displaying Information from the Protection Database

This section describes the commands you can use to display Protection Database entries and associated information. In addition to name and AFS ID, the Protection Database stores the following information about each user, machine, or group entry.

- The entry's owner, which is the user or group of users who can administer the entry

- The entry's creator, which serves mostly as an audit trail

- A membership count, which indicates how many groups a user or machine belongs to, or how many members belong to a group

- A set of privacy flags, which control which users can administer or display information about the entry

- A group-creation quota, which defines how many groups a user can create

- A list of the groups to which a user or machine belongs, or of the users and machines that belong to a group

- A list of the groups that a user or group owns

### To display a Protection Database entry

1. Verify that you belong to the system:administrators group, which enables you to display an entry regardless of the setting of its first (s) privacy flag. By default, any user can display a Protection Database entry. 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

2. Issue the pts examine command to display one or more Protection Database entries.

          % pts examine <user or group name or id>+

   where

   e

     Is the shortest acceptable abbreviation of examine (and check is an alias).

   user or group name or id

     Specifies the name or AFS ID of each entry to display. Precede any AFS GID with a hyphen (-) because it is a negative integer.

The output includes the following fields. Examples follow.

`Name`

  Specifies the entry's name.

  - For a user, this is the name used when authenticating with AFS and the name that appears on ACL entries.

  - For a machine, this is the IP address of a single machine, or a wildcard notation that represents a group of machines with consecutive IP addresses, as described in Creating User and Machine Entries.

  - For a group, this is the name that appears on ACL entries and in the list of groups output by the pts membership command. The names of regular groups have two parts, separated by a colon (:). The part before the colon indicates the group's owner, and the part after is the unique name. A prefix-less group's name does not have the owner prefix; only members of the system:administrators group can create prefix-less groups. For further discussion of group names, see Creating Groups.

`id`

  Specifies the entry's unique AFS identification number. For user and machine entries, the AFS user ID (AFS UID) is a positive integer; for groups, the AFS group ID (AFS GID) is a negative integer. AFS UIDs and GIDs have the same function as their counterparts in the UNIX file system, but are used by the AFS servers and the Cache Manager only.

  Normally, the Protection Server assigns an AFS UID or GID automatically when you create Protection Database entries. Members of the system:administrators group can specify an ID if desired. For further discussion, see Creating User and Machine Entries and Creating Groups.

`owner`

  Names the user or group who owns the entry and therefore can administer it (for more information about a group owning another group, see Using Groups Effectively). Other users possibly have administrative privileges, too, depending on the setting of the entry's privacy flags. For instructions on changing the owner, see Changing a Group's Owner.

`creator`

  Names the user who created the entry, and serves as an audit trail. If the entry is deleted from the Protection Database, the creator's group creation quota increases by one, even if the creator no longer owns the entry; see Setting Group-Creation Quota.

  The value `anonymous` in this field generally indicates that the entry was created when the Protection Server was running in no-authentication mode, probably during initial configuration of the cell's first file server machine. For a description of no-authentication mode, see Managing Authentication and Authorization Requirements.

`membership`

  Specifies the number of groups to which the user or machine belongs, or the number of users or machines that belong to the group.

`flags`

  Specifies who can display or change information in a Protection Database entry. The five flags, each representing a different capability, always appear in the same order.

  - For user entries, the default value is `S----`, which indicates that anyone can issue the pts examine command on the entry, but only the user and members of the system:administrators group can perform any other action.

  - For machine entries, the default value is `S----`, which indicates that anyone can issue the pts examine command on the entry, but only members of the system:administrators group can perform any other action.

  - For group entries, the default value is `S-M--`, which indicates that anyone can issue the pts examine and pts membership commands on the entry, but only the group's owner and members of the system:administrators group can perform any other action.

  For a complete description of possible values for the flags, see Setting the Privacy Flags on Database Entries.

`group quota`

  Specifies how many more groups a user can create in the Protection Database. The value for a newly created user entry is 20, but members of the system:administrators group can issue the pts setfields command at any time to change the value; see Setting Group-Creation Quota.

  Group creation quota has no meaning for a machine or group entry: the Protection Server recognizes the issuer of the pts creategroup command only as an authenticated user or as the anonymous user, never as a machine or group. The default value for group entries is 0 (zero), and there is no reason to change it.

The following examples show the output for a user called pat, a machine with IP address 192.12.108.133 and a group called terry:friends:

       % pts examine pat
       Name: pat, id: 1020, owner: system:administrators, creator: admin,
         membership: 12, flags: S----, group quota: 15.
       % pts ex 192.12.108.133
       Name: 192.12.108.133, id: 5151, owner: system:administrators, creator: admin,
         membership: 1, flags: S----, group quota: 20.
       % pts examine terry:friends
       Name: terry:friends, id: -567, owner: terry, creator: terry,
         membership: 12, flags: SOm--, group quota: 0.

### To display group membership

1. Verify that you belong to the system:administrators group, which enables you to display an entry's group membership information regardless of the setting of its third (m) privacy flag. By default the owner and the user can display group membership for a user entry, the owner for a machine entry, and anyone for a group entry. 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

2. Issue the pts membership command to display the list of groups to which a user or machine belongs, or the list of users and machines that belong to a group.

          % pts membership <user or group name or id>+

   where

   m

     Is the shortest acceptable abbreviation of membership.

   user or group name or id

     Specifies the name or AFS UID of each user or machine for which to list the groups it belongs to, or the name or AFS GID of each group for which to list the members.

For user and machine entries, the output begins with the following string, and then each group appears on its own line:

       Groups user_or_machine (id: AFS_UID) is a member of:

For group entries, the output begins with the following string, and then each member appears on its own line:

       Members of group (id: AFS_GID) are:

For the system groups system:anyuser and system:authuser, the output includes the initial header string only, because these groups do not have a stable membership listed in their Protection Database entry. See The System Groups.

The following examples show the output for a user called terry and a group called terry:friends:

       % pts mem terry
       Groups terry (id: 5347) is a member of:
         pat:friends
         sales
         acctg:general
       % pts mem terry:friends
       Members of terry:friends (id: -567) are:
         pat
         smith
         johnson

### To list the groups that a user or group owns

1. Verify that you belong to the system:administrators group, which enables you to display an entry's group ownership information regardless of the setting of its second (o) privacy flag. By default the owner can list the groups owned by group, and a user the groups he or she owns. 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

2. Issue the pts listowned command to list the groups owned by each user or group.

          % pts listowned <user or group name or id>+

   where

   listo

     Is the shortest acceptable abbreviation of listowned.

   user or group name or id

     Specifies the name or AFS UID of each user, or the name or AFS GID or each group, for which to list the groups owned.

The output begins with the following string, and then each group appears on its own line:

       Groups owned by user_or_group (id: AFS_ID) are:

The following examples show the output for a user called terry and a group called terry:friends:

       % pts listo terry
       Groups owned by terry (id: 5347) are:
         terry:friends
         terry:co-workers
       % pts listo terry:friends
       Groups owned by terry:friends (id: -567) are:
         terry:pals
         terry:buddies

### To display all Protection Database entries

1. 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

2. Issue the pts listentries command to display all Protection Database entries.

          % pts listentries [-users] [-groups]

   where

   liste

     Is the shortest acceptable abbreviation of listentries.

   -users

     Displays user and machine entries. The same output results if you omit both this flag and the -groups flag.

   -groups

     Displays group entries.

The output is a table that includes the following columns. Examples follow.

`Name`

  Specifies the entry's name.

`ID`

  Specifies the entry's AFS identification number. For user and machine entries, the AFS user ID (AFS UID) is a positive integer; for groups, the AFS group ID (AFS GID) is a negative integer.

`Owner`

  Specifies the AFS ID of the user or group who owns the entry and therefore can administer it.

`Creator`

  Specifies the AFS UID of the user who created the entry.

The following example is from the Example Corporation cell. The issuer provides no options, so the output includes user and machine entries.

       % pts listentries
       Name                          ID  Owner Creator
       anonymous                  32766   -204    -204
       admin                          1   -204   32766
       pat                         1000   -204       1
       terry                       1001   -204       1
       smith                       1003   -204       1
       jones                       1004   -204       1
       192.12.105.33               2000   -204       1
       192.12.105.46               2001   -204       1

## Creating User and Machine Entries

An entry in the Protection Database is one of the two required components of every AFS user account, along with an entry in the Authentication Database. It is best to create a Protection Database user entry only in the context of creating a complete user account, by using the uss add or uss bulk command as described in Creating and Deleting User Accounts with the uss Command Suite, or the pts createuser command as described in Creating AFS User Accounts.

You can also use the pts createuser command to create Protection Database machine entries, which can then be used to control access based on the machine from which the access request originates. After creating a machine entry, add it to a Protection Database group and place the group on ACLs ( a machine cannot appear on ACLs directly). Because all replicas of a volume share the same ACL (the one on the volume's root directory mount point), you can replicate the volume that houses a program's binary file while still complying with a machine-based license agreement as required by the program's manufacturer. If you do not place any other entries on the ACL, then only users working on the designated machines can access the file.

Keep in mind that creating an ACL entry for a group with machine entries in it extends access to both authenticated and unauthenticated users working on the machine. However, you can deny access to unauthenticated users by omitting an entry for the system:anyuser group from the ACLs of the parent directories in the file's pathname. Conversely, if you want to enable unauthenticated users on the machine to access a file, then the ACL on every directory leading to it must include an entry for either the system:anyuser group or a group to which the machine entry belongs. For more information on the system:anyuser group, see The System Groups.

Because a machine entry can include unauthenticated users, it is best not to add both machine entries and user entries to the same group. In general, it is easier to use and administer nonmixed groups. A machine entry can represent a single machine, or multiple machines with consecutive IP addresses (that is, all machines on a network or subnet) specified by a wildcard notation. See the instructions in To create machine entries in the Protection Database.

By default, the Protection Server assigns the next available AFS UID to a new user or machine entry. It is best to allow this, especially for machine entries. For user entries, it makes sense to assign an AFS UID only if the user already has a UNIX UID that the AFS UID needs to match (see Assigning AFS and UNIX UIDs that Match). When automatically allocating an AFS UID, the Protection Server increments the `max user id` counter by one and assigns the result to the new entry. Use the pts listmax command to display the counter, as described in Displaying and Setting the AFS UID and GID Counters.

Do not reuse the AFS UIDs of users who have left your cell permanently or machine entries you have removed, even though doing so seems to avoid the apparent waste of IDs. When you remove a user or machine entry from the Protection Database, the fs listacl command displays the AFS UID associated with the former entry, rather than the name. If you then assign the AFS UID to a new user or machine, the new user or machine automatically inherits permissions that were granted to the previous possessor of the ID. To remove obsolete AFS UIDs from ACLs, use the fs cleanacl command described in Removing Obsolete AFS IDs from ACLs.

In addition to the name and AFS UID, the Protection Server records the following values in the indicated fields of a new user or machine's entry. For more information and instructions on displaying an entry, see To display a Protection Database entry.

- It sets the `owner` field to the system:administrators group, indicating that the group's members administer the entry.

- It sets the `creator` field to the username of the user who issued the pts createuser command (or the uss add or uss bulk command).

- It sets the `membership` field to 0 (zero), because the new entry does not yet belong to any groups.

- It sets the `flags` field to S----; for explanation, see Setting the Privacy Flags on Database Entries.

- It sets the `group quota` field to 20, meaning that the new user can create 20 groups. This field has no meaning for machine entries. For further discussion, see Setting Group-Creation Quota.

### To create machine entries in the Protection Database

1. 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

2. Issue the pts createuser command to create one or more machine entries.

          % pts createuser -name <user name>+

   where

   cu

     Is an alias for createuser (and createu is the shortest acceptable abbreviation).

   -name

     Specifies an IP address in dotted-decimal notation for each machine entry. An entry can represent a single machine or a set of several machines with consecutive IP addresses, using the wildcard notation described in the following list. The letters W, X, Y, and Z each represent an actual number value in the field:

     - W.X.Y.Z represents a single machine, for example 192.12.108.240.

     - W.X.Y.0 matches all machines whose IP addresses start with the first three numbers. For example, 192.12.108.0 matches both 192.12.108.119 and 192.12.108.120, but does not match 192.12.105.144.

     - W.X.0.0 matches all machines whose IP addresses start with the first two numbers. For example, the address 192.12.0.0 matches both 192.12.106.23 and 192.12.108.120, but does not match 192.5.30.95.

     - W.0.0.0 matches all machines whose IP addresses start with the first number in the specified address. For example, the address 192.0.0.0 matches both 192.5.30.95 and 192.12.108.120, but does not match 138.255.63.52.

     Do not define a machine entry with the name 0.0.0.0 to match every machine. The system:anyuser group is equivalent.

The following example creates a machine entry that includes all of the machines in the 192.12 network.

       % pts cu 192.12.0.0

## Creating Groups

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.

### Using Groups Effectively

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.

### To create groups

1. 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

2. 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

   cg

     Is an alias for creategroup (and createg is the shortest acceptable abbreviation).

   -name

     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.)

   -owner

     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.

### To create a self-owned group

1. 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>

2. 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>+

3. 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>

### Using Prefix-Less Groups

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.

## Adding and Removing Group Members

Users and machines can be members of groups; groups cannot belong to other groups. Newly created groups have no members at all. To add them, use the pts adduser command; to remove them, use the pts removeuser command.

### To add users and machines to groups

1. Verify that you belong to the system:administrators group, which enables you to add members to a group regardless of the setting of its fourth (a) privacy flag. By default the group's owner also has the necessary privilege. 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

2. Issue the pts adduser command to add one or more members to one or more groups.

          % pts adduser -user <user name>+ -group <group name>+

   where

   ad

     Is the shortest acceptable abbreviation of adduser.

   -user

     Specifies each username or machine IP address to add as a member of each group named by the -group argument. A group cannot belong to another group.

   group name

     Names each group to which to add the new members.

### To remove users and machines from groups

1. Verify that you belong to the system:administrators group, which enables you to remove members from a group regardless of the setting of its fifth (r) privacy flag. By default the group's owner also has the necessary privilege. 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

2. Issue the pts removeuser command to remove one or more members from one or more groups.

          % pts removeuser -user  <user name>+  -group <group name>+

   where

   rem

     Is the shortest acceptable abbreviation of removeuser.

   -user

     Specifies each user or machine IP address to remove from each group named by the -group argument.

   -group

     Names each group from which to remove members.

## Deleting Protection Database Entries

It is best to delete a Protection Database user entry only if you are removing the complete user account. Use either the uss delete command as described in Deleting Individual Accounts with the uss delete Command, or the pts delete command as described in Removing a User Account.

To remove machine and group entries, use the pts delete command as described in this section. The operation has the following results:

- When you delete a machine entry, its name (IP address wildcard) is removed from groups.

- When you delete a group entry, its AFS GID appears on ACLs instead of the name. The group-creation quota of the user who created the group increases by one, even if the user no longer owns the group.

  To remove obsolete AFS IDs from ACLs, use the fs cleanacl command as described in Removing Obsolete AFS IDs from ACLs.

### To delete Protection Database entries

1. Verify that you belong to the system:administrators group or own the group you are deleting. 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

2. Issue the pts delete command to delete one or more entries from the Protection Database.

          % pts delete <user or group name or id>+

   where

   del

     Is the shortest acceptable abbreviation of delete.

   user or group name or id

     Specifies the IP address or AFS UID of each machine or the name or AFS GID or each group to remove.

## Changing a Group's Owner

For user and machine entries, the Protection Server automatically assigns ownership to the system:administrators group at creation time, and this cannot be changed. For group entries, you can change ownership. This transfers administrative responsibility for it to another user or group (for information on group ownership of other groups, see Using Groups Effectively).

When you create a regular group, its owner_name prefix must accurately reflect its owner, as described in To create groups:

- If the owner is a user, owner_name is the username.

- If the owner is a regular group, owner_name is the owning group's owner_name prefix.

- If the owner is a prefix-less group, owner_name is the owner group's name.

When you change a regular group's owner, the Protection Server automatically changes its owner_name prefix appropriately. For example, if the user pat becomes the new owner of the group terry:friends, its name automatically changes to pat:friends, both in the Protection Database and on ACLs.

However, the Protection Server does not automatically change the owner_name prefix of any regular groups that the group owns. To continue with the previous example, suppose that the group terry:friends owns the group terry:pals. When pat becomes the new owner of terry:friends, the name terry:pals does not change. To change the owner_name prefix of a regular group that is owned by another group (in the example, to change the group's name to pat:pals), use the pts rename command as described in Changing a Protection Database Entry's Name.

### To change a group's owner

1. Verify that you belong to the system:administrators group or own the group for which you are changing the owner. 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

2. (Optional) If you are changing the group's owner to another group (or to itself) and want to retain administrative privilege on the owned group, verify that you belong to the new owner group. If necessary, issue the pts membership command, which is fully described in To display group membership.

          % pts membership <user or group name or id>

   Use the pts adduser command to add yourself if necessary, as fully described in To add users and machines to groups.

          % pts adduser <user name> <group name>

3. Issue the pts chown command to change the group's owner.

          % pts chown <group name> <new owner>

   where

   cho

     Is the shortest acceptable abbreviation of chown.

   group name

     Specifies the current name of the group.

   new owner

     Names the user or group to become the group's owner.

4. (Optional) Issue the pts listowned command to display any groups that the group owns. As discussed in the introduction to this section, the pts chown command does not automatically change the owner_name prefix of any regular groups that a group owns.

          % pts listowned <user or group name or id>

   If you want to change their names to match the new owning group, use the pts rename command on each one, as described in To change the name of a machine or group entry.

          % pts rename <old name> <new name>

## Changing a Protection Database Entry's Name

To change the name of a Protection Database entry, use the pts rename command. It is best to change a user entry's name only when renaming the entire user account, since so many components of the account (Authentication Database entry, volume name, home directory mount point, and so on) share the name. For instructions, see Changing Usernames. A machine entry's name maps to the actual IP address of one or more machine, so changing the entry's name is appropriate only if the IP addresses have changed.

It is likely, then, that most often you need to change group names. The following types of name changes are possible:

- Changing a regular group's name to another regular group name. The most common reason for this type of change is that you have used the pts chown command to change the owner of the group. That operation does not change the owner_name prefix of a regular group owned by the group whose name has been changed. Therefore, you must use the pts rename command to change it appropriately. For example, when user pat becomes the owner of the terry:friends group, its name changes automatically to pat:friends, but the name of a group it owns, terry:pals, does not change. Use the pts rename command to rename terry:pals to pat:pals. The Protection Server does not accept changes to the owner_name prefix that do not reflect the true ownership (changing terry:pals to smith:pals is not possible).

  You can also use the pts rename command to change the group_name portion of a regular group name, with or without changing the owner_name prefix.

  Both the group's owner and the members of the system:administrators group can change its name to another regular group name.

- Changing a regular group's name to a prefix-less name. If you change a group's name in this way, you must also use the pts rename command to change the name of any regular group that the group owns. Only members of the system:administrators group can make this type of name change.

- Changing a prefix-less name to another prefix-less name. As with other name changes, the owner_name prefix of any regular groups that the prefix-less group owns does not change automatically. You must issue the pts rename command on them to maintain consistency.

  Both the group's owner and the members of the system:administrators group can change its name to another prefix-less name.

- Changing a prefix-less name to a regular name. The owner_name prefix on the new name must accurately reflect the group's ownership. As with other name changes, the owner_name prefix of any regular groups that the prefix-less group owns does not change automatically. You must issue the pts rename command on them to maintain consistency.

  Only members of the system:administrators group can make this type of name change.

### To change the name of a machine or group entry

1. 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

2. Issue the pts rename command to change the entry's name.

          % pts rename <old name> <new name>

   where

   ren

     Is the shortest acceptable abbreviation of rename.

   old name

     Specifies the entry's current name.

   new name

     Specifies the new name. If the new name is for a regular group, the owner_name prefix must correctly indicate the owner.

## Setting Group-Creation Quota

To prevent abuse of system resources, the Protection Server imposes a group-creation quota that limits how many more groups a user can create. When a new user entry is created, the quota is set to 20, but members of the system:administrators group can use the pts setfields command to increase or decrease it at any time.

It is pointless to change group-creation quota for machine or group entries. It is not possible to authenticate as a group or machine and then create groups.

To display the group-creation quota, use the pts examine command to display a user entry's `group quota field`, as described in To display a Protection Database entry.

### To set group-creation quota

1. 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

2. Issue the pts setfields command to specify how many more groups each of one or more users can create.

         % pts setfields -nameorid <user or group name or id>+  \
                         -groupquota <set limit on group creation>

   where

   setf

     Is the shortest acceptable abbreviation of setfields.

   -nameorid

     Specifies the name or AFS UID of each user for which to set group-creation quota.

   -groupquota

     Defines how many groups each user can create in addition to existing groups (in other words, groups that already exist do not count against the quota). The value you specify overwrites the current value, rather than incrementing it.

## Setting the Privacy Flags on Database Entries

Members of the system:administrators group can always display and administer Protection Database entries in any way, and regular users can display and administer their own entries and any group entries they own. The privacy flags on a Protection Database entry determine who else can display certain information from the entry, and who can add and remove members in a group.

To display the flags, use the pts examine command as described in To display a Protection Database entry. The flags appear in the output's `flags` field. To set the flags, include the -access argument to the pts setfields command.

The five flags always appear, and always must be set, in the following order:

s

  Controls who can issue the pts examine command to display the entry.

o

  Controls who can issue the pts listowned command to display the groups that a user or group owns.

m

  Controls who can issue the pts membership command to display the groups a user or machine belongs to, or which users or machines belong to a group.

a

  Controls who can issue the pts adduser command to add a user or machine to a group. It is meaningful only for groups, but a value must always be set for it even on user and machine entries.

r

  Controls who can issue the pts removeuser command to remove a user or machine from a group. It is meaningful only for groups, but a value must always be set for it even on user and machine entries.

Each flag can take three possible types of values to enable a different set of users to issue the corresponding command:

- A hyphen (-) designates the members of the system:administrators group and the entry's owner. For user entries, it designates the user in addition.

- The lowercase version of the letter applies meaningfully to groups only, and designates members of the group in addition to the individuals designated by the hyphen.

- The uppercase version of the letter designates everyone.

For example, the flags `SOmar` on a group entry indicate that anyone can examine the group's entry and display the groups that it owns, and that only the group's members can display, add, or remove its members.

The default privacy flags for user and machine entries are `S----`, meaning that anyone can display the entry. The ability to perform any other functions is restricted to members of the system:administrators group and the entry's owner (as well as the user for a user entry).

The default privacy flags for group entries are `S-M--`, meaning that all users can display the entry and the members of the group, but only the entry owner and members of the system:administrators group can perform other functions.

### To set a Protection Database entry's privacy flags

1. 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

2. Issue the pts setfields command to set the privacy flags.

          % pts setfields <user or group name or id>+ -access <set privacy flags>

   where

   setf

     Is the shortest acceptable abbreviation of setfields.

   user or group name or id

     Specifies the name or AFS UID of each user, the IP address or AFS UID of each machine, or the name or AFS GID of each group for which to set the privacy flags.

   -access

     Specifies the set of privacy flags to associate with each entry. Provide a value for each of the five flags, observing the following constraints:

     - Provide a value for all five flags, even though the fourth and fifth flags are not meaningful for user and machine entries.

     - For self-owned groups, the hyphen is equivalent to a lowercase letter, because all the members of a self-owned group own it.

     - Set the first flag to lowercase s or uppercase S only. For user and machine entries, the Protection Server interprets the lowercase s as equivalent to the hyphen.

     - Set the second flag to the hyphen (-) or uppercase O only. For groups, the Protection Server interprets the hyphen as equivalent to lowercase o (that is, members of a group can always list the groups that it owns).

     - Set the third flag to the hyphen (-), lowercase m, or uppercase M. For user and machine entries, the lowercase m does not have a meaningful interpretation, because they have no members.

     - Set the fourth flag to the hyphen (-), lowercase a, or uppercase A. Although this flag does not have a meaningful interpretation for user and machine entries (because they have no members), it must be set, preferably to the hyphen.

     - Set the fifth flag to the hyphen (-) or lowercase r only. Although this flag does not have a meaningful interpretation for user and machine entries (because they have no members), it must be set, preferably to the hyphen.

## Displaying and Setting the AFS UID and GID Counters

When you use the pts createuser command to create a user or machine entry in the Protection Database, the Protection Server by default automatically allocates an AFS user ID (AFS UID) for it; similarly, it allocates an AFS group ID (AFS GID) for each group entry you create with the pts creategroup command. It tracks the next available AFS UID (which is a positive integer) and AFS GID (which is a negative integer) with the `max user id` and `max group id` counters, respectively.

Members of the system:administrators group can include the -id argument to either pts creation command to assign a specific ID to a new user, machine, or group. It often makes sense to assign AFS UIDs explicitly when creating AFS accounts for users with existing UNIX accounts, as discussed in Assigning AFS and UNIX UIDs that Match. It is also useful if you want to establish ranges of IDs that correspond to departmental affiliations (for example, assigning AFS UIDs from 300 to 399 to members of one department, AFS UIDs from 400 to 499 to another department, and so on).

To display the current value of the counters, use the pts listmax command. When you next create a user or machine entry and do not specify its AFS UID, the Protection Server increments the `max user id` counter by one and assigns that number to the new entry. When you create a new group and do not specify its AFS GID, the Protection Server decrements the `max group id` counter by one (makes it more negative), and assigns that number to the new group.

You can change the value of either counter, or both, in one of two ways:

- Directly, using the pts setmax command.

- Indirectly, by using the -id argument to the pts createuser command to assign an AFS UID that is larger than the `max user id` counter, or by using the -id to the pts creategroup command to assign an AFS GID that is less (more negative) than the max group id counter. In either case, the Protection Server changes the counter to the value of the -id argument. The Protection Server does not use the IDs between the previous value of the counter and the new one when allocating IDs automatically, unless you use the pts setmax command to move the counter back to its old value.

  If the value you specify with the -id argument is less than the `max user id` counter or greater (less negative) than the `max group id` counter, then the counter does not change.

### To display the AFS ID counters

1. Issue the pts listmax command to display the counters.

          % pts listmax

   where listm is an acceptable abbreviation of listmax.

The following example illustrates the output's format. In this case, the next automatically assigned AFS UID is 5439 and AFS GID is -469.

       % pts listmax
       Max user id is 5438 and max group id is -468.

### To set the AFS ID counters

1. 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

2. Issue the pts setmax command to set the `max user id` counter, the `max group id` counter, or both.

          % pts setmax [-group <group max>] [-user <user max>]

   where

   setm

     Is the shortest acceptable abbreviation of setmax.

   -group

     Specifies an integer one greater (less negative) than the AFS GID that the Protection Server is to assign to the next group entry. Because the value is a negative integer, precede it with a hyphen (-).

   -user

     Specifies an integer one less than the AFS UID that the Protection Server is to assign to the next user or machine entry.