| Using AFS Protection Groups | ||
|---|---|---|
 | Chapter 2. Issues in Cell Configuration and Administration |  |
| Using AFS Protection Groups | ||
|---|---|---|
| | Chapter 2. Issues in Cell Configuration and Administration | |
AFS enables users to define their own groups of other users or machines. The groups are placed on ACLs to grant the same permissions to many users without listing each user individually. For group creation instructions, see Administering the Protection Database.
Groups have AFS ID numbers, just as users do, but an AFS group ID (GID) is a negative integer whereas a user's AFS UID is a positive integer. By default, the Protection Server allocates a new group's AFS GID automatically, but members of the system:administrators group can assign a GID when issuing the pts creategroup command. Before explicitly assigning a GID, it is best to verify that it is not already in use.
A group cannot belong to another group, but it can own another group or even itself as long as it (the owning group) has at least one member. The current owner of a group can transfer ownership of the group to another user or group, even without the new owner's permission. At that point the former owner loses administrative control over the group.
By default, each user can create 20 groups. A system administrator can increase or decrease this group creation quota with the pts setfields command.
Each Protection Database entry (group or user) is protected by a set of five privacy flagswhich limit who can administer the entry and what they can do. The default privacy flags are fairly restrictive, especially for user entries. See Setting the Privacy Flags on Database Entries.
As the Protection Server initializes for the first time on a cell's first database server machine, it automatically creates three group entries: the system:anyuser, system:authuser, and system:administrators groups.
The first two system groups are unlike any other groups in the Protection Database in that they do not have a stable membership:
The system:anyuser group includes everyone who can access a cell's AFS filespace: users who have tokens for the local cell, users who have logged in on a local AFS client machine but not obtained tokens (such as the local superuser root), and users who have connected to a local machine from outside the cell. Placing the system:anyuser group on an ACL grants access to the widest possible range of users. It is the only way to extend access to users from foreign AFS cells that do not have local accounts.
The system:authuser group includes everyone who has a valid token obtained from the cell's AFS authentication service.
Because the groups do not have a stable membership, the pts membership command produces no output for them. Similarly, they do not appear in the list of groups to which a user belongs.
The system:administrators group does have a stable membership, consisting of the cell's privileged administrators. Members of this group can issue any pts command, and are the only ones who can issue several other restricted commands (such as the chown command on AFS files). By default, they also implicitly have the a (administer) and l (lookup) permissions on every ACL in the filespace. For information about changing this default, see Administering the system:administrators Group.
For a discussion of how to use system groups effectively on ACLs, see Using Groups on ACLs.
All users can create regular groups. A regular group name has two fields separated by a colon, the first of which must indicate the group's ownership. The Protection Server refuses to create or change the name of a group if the result does not accurately indicate the ownership.
Members of the system:administrators group can create prefix-less groups whose names do not have the first field that indicates ownership. For suggestions on using the two types of groups effectively, see Using Groups Effectively.
| |  | |
| Configuring AFS User Accounts |  | Login and Authentication in AFS |