Chapter 4
Administering Perforce:
Protections
Perforce provides a protection scheme to prevent unauthorized or inadvertent access to the depot. The protections determine which Perforce commands can be run, on which files, by whom, and from which host. Protections are set with the p4 protect command.
When Should Protections Be Set?
Before p4 protect is run, every Perforce user is a superuser, and can access and change anything in the depot. The first time protect is invoked, a protections table is created that gives the invoking user superuser access from all hosts, and lowers everyone else's access level to write permission on all files from all hosts. Therefore, protect should be run as the concluding step of all new Perforce installations; the superuser can change the access levels as needed at any time.
The Perforce protections are stored in the db.protect file in the server root directory; if p4 protect is first run by an unauthorized user (or if you accidentally lock yourself out!) the depot can be brought back to its unprotected state by removing this file.
Setting Protections with "p4 protect"
The p4 protect form contains a single form field called Protections: that consists of multiple lines. Each line in Protections: contains subfields, and the table looks like this:
Example:
A sample protections table:
|
Protections:
read user emily * //depot/elm_proj/...
write group devgrp * //...
write user * 195.3.24.* -//...
write user joe * -//...
write user lisag * -//depot/...
write user lisag * //depot/doc/...
super user edk * //...
|
(The five fields may not line up vertically on your screen; they are aligned here for readability.)
The permission lines' five fields
Each line specifies a particular permission; each permission is defined by five fields.
The meanings of these fields are:
Field
|
Meaning
|
|---|
|
Access Level
|
Which access level is being granted: list, read, open, write, review, admin, or super. These are described below.
|
|
User/Group
|
Does this protection apply to a user or a group? The value must be user or group.
|
|
Name
|
The user or group whose protection level is being defined. This field may contain the "*" wildcard. A "*" by itself grants this protection to everyone, "*e" grants this protection to every user (or group) whose username ends with an "e".
|
|
Host
|
The TCP/IP address of the host being granted access. This must be provided as the numeric address of the host in dotted quad notation (for instance, 192.168.41.2).
This field may contain the "*" wildcard. A "*" by itself means that this protection is being granted for all hosts. The wildcard can be used as in any string, so "192.168.41.*" would define access to any subnet within 192.168.41, and "*3*" would refer to any IP address with a "3" in it.
Because the client's IP address is provided by the Internet Protocol itself, this field provides as much security as is provided by the network.
If you are using Perforce Proxy, see "P4P and protections" on page 123 to find out how to use host-based protections for users connecting to a Perforce Server from behind a Perforce Proxy.
|
|
Files
|
A file specification representing the files in the depot on which permissions are being granted. Perforce wildcards can be used in the specification.
"//..." means all files in all depots.
|
Access levels
The access level is described by the first value on each line. The seven access levels are:
Level
|
Meaning
|
|---|
|
list
|
Permission is granted to run Perforce commands that display file metadata, such as p4 filelog. No permission is granted to view or change the contents of the files.
|
|
read
|
The user(s) can run those Perforce commands that are needed to read files, such as p4 client and p4 sync. The read permission includes list access.
|
|
open
|
Grants permission to read files from the depot into the client workspace, and gives permission to open and edit those files. This permission does not allow the user to write the files back to the depot. open is similar to write, except that with open permission, users are not allowed to run p4 submit or p4 lock.
The open permission includes read and list access.
|
|
write
|
Permission is granted to run those commands that edit, delete, or add files. The write permission includes read, list, and open access.
This permission allows use of all Perforce commands except protect, depot, obliterate, and verify.
|
|
review
|
A special permission granted to review daemons. It includes list and read access, plus use of the p4 review command. Only review daemons require this permission.
|
|
admin
|
For Perforce administrators; grants permission to run Perforce commands that affect metadata, but not server operation. Provides write and review access plus the added ability to override other users' branch specifications, client specifications, jobs, labels, and change descriptions, as well as to update the typemap table, verify and obliterate files, and to customize job specifications.
|
|
super
|
For Perforce superusers; grants permission to run all Perforce commands. Provides write, review, and admin access plus the added ability to create depots and triggers, edit protections and user groups, delete users, reset passwords, and to shut down the server.
|
Each Perforce command is associated with a particular minimum access level. For example, to run p4 sync on a particular file, the user must have been granted at least read access on that file.
The access level required to run a particular command can usually be reasoned from knowledge of what the command does. For example, it is somewhat obvious that p4 print would require read access. For a full list of the minimum access levels required to run each Perforce command, see "How Protections are Implemented" on page 73.
Which users should receive which permissions?
The simplest method of granting permissions is to give write permission to all users who don't need to manage the Perforce system, and give super access to those who do, but there are times when this simple solution isn't sufficient.
Read access to particular files should be granted to users who don't ever need to edit those files. For example, an engineer might have write permission for source files, but have only read access to the documentation, while managers might be granted only read access to all files.
Because open access allows local editing of files, but doesn't allow these files to be written to the depot, open access is usually granted only in unusual circumstances. You might choose open access over write access when users are testing their changes locally, but when these changes should not be seen by other users. For instance, bug testers may want to change code in order to test theories as to why particular bugs occur, but these changes would be for their own use, and would not be written to the depot. Perhaps a codeline has been frozen, and local changes are to be submitted to the depot only after careful review by the development team. In these cases, open access would be granted until the code changes have been approved, after which time the protection level would be upgraded to write and the changes submitted.
Default protections
Before p4 protect is invoked, every user has superuser privileges. When p4 protect is first run, two permissions are set by default. The default protections table looks like this:
|
write user * * //...
super user edk * //...
|
This indicates that write access is granted to all users, on all hosts, to all files. Additionally, the user who first invoked p4 protect (in this case, edk) is granted superuser privileges.
Interpreting multiple permission lines
The access rights granted to any user are defined by the union of mappings in the protection lines that match her user name and client IP address. (This behavior is slightly different when exclusionary protections are provided and is described in the next section.)
Example:
Multiple Permission Lines
Lisa, whose Perforce username is lisag, is using a client with the IP address
195.42.39.17. The protections file reads as follows:
|
read user * 195.42.39.17 //...
write user lisag 195.42.39.17 //depot/elm_proj/doc/...
read user lisag * //...
super user edk * //...
|
The union of the first three permissions apply to Lisa. Her username is lisag, and she's
currently using a client workspace on the host specified in lines 1 and 2. Thus, she can write
files located in the depot's doc subdirectory, but can only read other files. Lisa tries the
following:
She types p4 edit //lisag/doc/elm-help.1, and is successful.
She types p4 edit //lisag/READ.ME, and is told that she doesn't have the proper
permission. She is trying to write to a file to which has only read access. She types p4 sync
//lisag/READ.ME, and this command succeeds, as only read access is needed, and this is
granted to her on line 1.
Lisa later switches to another machine with IP address 195.42.39.13. She types p4 edit
//lisag/doc/elm-help.1, and the command fails; when she's using this host, only the
third permission applies to her, and she only has read privileges.
Exclusionary protections
A user can be denied access to particular files by prefacing the fifth field in a permission line with a minus sign ("-"). This is useful for giving most users access to a particular set of files, while denying access to the same files to only a few users.
To use exclusionary mappings properly, it is necessary to understand some of their peculiarities:
The first permission looks like it grants write access to all users to all files in all depots, but
this is overruled by later exclusionary protections for certain users.
The third permission denies Joe permission to access any file from any host. No subsequent
lines grant Joe any further permissions; thus, Joe has been effectively locked out of Perforce.
The fourth permission denies Lisa all access to all files on all hosts, but the fifth permission
gives her back write access on all files within a specific directory. If the fourth and fifth lines
were switched, Lisa would be unable to run any Perforce command.
Granting Access to Groups of Users
Perforce groups simplify maintenance of the protections table. The names of users with identical access requirements can be stored in a single group; the group name can then be entered in the table, and all the users in that group receive the specified permissions.
Groups are maintained with p4 group and their protections assigned with p4 protect. Only Perforce superusers may use these commands.
Creating and editing groups
If p4 group groupname is called with a non-existent groupname, a new group named groupname is created. Calling p4 group with an existing groupname allows editing of the user list for this group.
The command p4 group groupname displays a form with two fields: Group: and Users:. The Group: field stores the group name, and cannot be edited; Users: is empty when the group is first created, and must be filled in. User names are entered under the Users: field header; each user name must be typed on its own line, and should be indented. A single user may be listed in any number of groups.
As of Release 99.2, groups can contain other groups, not just users. To add all users in a previously defined group to the group you're presently working with, include the group name in the Subgroups: field of the p4 group form. User and group names occupy separate namespaces, so groups and users can have the same names.
Groups and protections
To use a group with the p4 protect form, specify a group name instead of a user name in any line in the protections table, and set the value of the second field on the line to group instead of user. All the users in that group will be granted the specified access.
Example:
Granting access to Perforce groups.
This protections table grants list access to all members of the group devgrp, and super
access to user edk:
|
list group devgrp * //...
super user edk * //...
|
If a user belongs to multiple groups, one permission may override another, but the actual permissions granted to a specific user can be determined by replacing the names of all groups that a particular user belongs to with the user's name within the protections table, and applying the rules described earlier in this chapter.
Deleting groups
To delete a group, invoke
Alternately, invoke p4 group groupname and delete all the users from the group in the resulting editor form. The group will be deleted when the form is closed.
How Protections are Implemented
This section describes the algorithm that Perforce follows to implement its protection scheme. Protections can be used properly without reading this section, as the material here is provided to explain the logic behind the behavior described above.
Users' access to files is determined by the following steps:
- The command is looked up in the command access level table shown in "Access Levels Required by Perforce Commands" on page 74 to determine the minimum access level needed to run that command. In our example, p4 print is the command, and the minimum access level required to run that command is read.
- Perforce makes the first of two passes through the protections table. Both passes move up the protections table, bottom to top, looking for the first relevant line.
- The first pass determines whether or not the user is allowed to know whether or not the file exists. This search simply looks for the first line encountered that matches the user name, host IP address, and file argument. If the first matching line found is an inclusionary protection, then the user has permission to at least list the file, and Perforce proceeds to the second pass. Otherwise, if the first matching protection found is an exclusionary mapping, or if the top of the protections table is reached without a matching protection being found, then the user has no permission to even list the file, and will receive a message like File not on client.
Example:
Interpreting the order of mappings in the protections table.
Suppose that our protections table is set as follows:
|
write user * * //...
read user edk * -//...
read user edk * //depot/elm_proj/...
|
If Ed runs p4 print //depot/foo, Perforce examines the protections table bottom to top,
and first encounters the last line. The files specified there don't match the file that Ed wants to
print, so this line is irrelevant. The second-to-last line is examined next; this line matches Ed's
user name, his IP address, and the file he wants to print; since this line is an exclusionary
mapping, Ed isn't allowed to even list the file.
- If the first pass is successful, a second pass is made at the protections table; this pass is the same as the first, except that access level is now taken into account.
- If an inclusionary protection line is the first line encountered that matches the user name, IP address, file argument, and has an access level greater than or equal to the access level required by the given command, then the user is given permission to run the command.
- If an exclusionary mapping is the first line encountered that matches according to the above criteria, or if the top of the protections table is reached without finding a matching protection, then the user has no permission to run the command, and will receive the message "You don't have permission for this operation".
Access Levels Required by Perforce Commands
The following table lists the minimum access level required to run each command. For example, since p4 add requires at least open access, p4 add can be run if open, write, admin, or super protections are granted.
Command
|
Access Level
|
Command
|
Access Level
|
|---|
|
add
|
open
|
integrate d
|
open
|
|
admin
|
super
|
integrated
|
list
|
|
annotate
|
read
|
job b e
|
open
|
|
branch e
|
open
|
jobs a
|
list
|
|
branches
|
list
|
jobspec b
|
admin
|
|
change e
|
open
|
label a e
|
open
|
|
changes a
|
list
|
labels a b
|
list
|
|
client e
|
list
|
labelsync
|
open
|
|
clients
|
list
|
lock
|
write
|
|
counter c
|
review
|
obliterate
|
admin
|
|
counters
|
list
|
opened
|
list
|
|
delete
|
open
|
passwd
|
list
|
|
depot a b
|
super
|
print
|
read
|
|
depots a
|
list
|
protect a
|
super
|
|
describe
|
read
|
reopen
|
open
|
|
describe -s
|
list
|
resolve
|
open
|
|
diff
|
read
|
resolved
|
open
|
|
diff2
|
read
|
revert
|
open
|
|
dirs
|
list
|
review a
|
review
|
|
edit
|
open
|
reviews a
|
list
|
|
filelog
|
list
|
set
|
list
|
|
files
|
list
|
submit
|
write
|
|
fix a
|
open
|
sync
|
read
|
|
fixes a
|
list
|
triggers
|
super
|
|
fstat
|
list
|
typemap
|
admin
|
|
group a b
|
super
|
unlock e
|
open
|
|
groups a
|
list
|
user a b
|
list
|
|
have
|
list
|
users a
|
list
|
|
help
|
none
|
verify
|
admin
|
|
info
|
none
|
where a
|
none
|
a This command doesn't operate on specific files. Thus, permission is granted to run the command if the user has the specified access to at least one file in the depot.
b The -o flag to this command, which allows the form to be read but not edited, requires only list access.
c list access is required to view an existing counter's value; review access is required to change a counter's value or create a new counter.
d To run p4 integrate, the user needs open access on the target files and read access on the donor files.
e The -f flag to override existing metadata or other users' data requires admin access.
Those commands that list files, such as p4 describe, will only list those files to which the user has at least list access.
Some of these commands (for instance, p4 change, when editing a previously submitted changelist) take a -f flag which can only be used by Perforce superusers. See "Forcing operations with the -f flag" on page 47 for details.
Please send comments and questions about this manual to
[email protected].
Copyright 1999-2003 Perforce Software. All rights reserved.
Last updated: 07/07/03