[Top] [Prev] [Next]

System Administration:
Protections

Perforce provides a protection scheme to prevent unauthorized or inadvertent access to the depot. The protections determines which Perforce commands can be run, on which files, by whom, and from which host. Since any user can change their Perforce username with P4USER, user level protections provide safety, not security. At the host level, protections are as secure as the host itself.

Protections are set with the p4 protect command.

When Should Protections Be Set?

Before p4 protect is run, there are no protections against a user running Perforce commands that access or change the depot. The first time protect is invoked, a protections table is created that gives the invoking user superuser access from all hosts. Therefore, protect should be run as the concluding step of all new Perforce installations.

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, 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 field with multiple lines. Each line specifies a particular permission; the contents look something like this:


Protections: `read emily * //depot/elm_proj/...` write * 195.3.21.* //... `write joe * -//...write lisag * -//depot/...` write lisag * //depot/doc/... `super edk * //...`

(The four fields may not line up vertically on your screen; they are aligned here for ease of reading).

The Permission Lines' Four Fields

Each line specifies a particular permission; each permission is always described by four fields. The meanings of these four fields are:


Field	Meaning
Access Level	Which access level is being granted: `list`, `read,` `write`, `super`, or `review`. These are described below.
User	The user whose protection level is being defined. This field can contain the ``'` wildcard: ``'` by itself would grant this protection to everyone; ``e'` `w`ould grant this protection to everyone whose username ends with an ``e'`. Since Perforce* usernames can be changed by setting `P4USER`, this field provides safety, not security.
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 (e.g. `206.14.52.194`). 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 ``127.30.41.'` would define access to any subnet within `127.30.41`, and ``3*'` would refer to any IP address with a ``3'` in it. Since the client's IP address is provided by IP itself, this field provides as much security as is provided by the network.
Files	The files in the depot that permission is being granted on. `//...' means all files in all depots.

Access Levels

The access level is described by the first field, and the five access levels are


Access Level	Meaning
`list`	Permission is granted to run Perforce commands that display data about files, (e.g. `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 get`. The `read` permission includes `list` access.
`write`	Permission is granted to run those commands that edit, delete, or add files. The `write` permission includes `read` and `list` 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. It is needed only by review daemons.
super	For Perforce superusers; grants permission to run all Perforce commands. Provides `write` and `review` access plus the added ability to edit protections, create depots, obliterate files, and verify files.

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. A full list of the minimum access levels required to run each Perforce command is provided at the end of this section.

Default Protections

When p4 protect is first run, two permissions are set by default. The default protect form looks like this:


Protections: write * * //... super edk * //...

This indicates that write access is granted to all users, on all hosts, to all files. Additionally, the user who first invokes 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 mappings in the protection lines that match his user name and client IP address. As in any other type of mapping, order matters: later lines have higher precedence.

Lisa, whose Perforce username is lisag, is using a client with the IP address 195.42.39.17. The protections file reads as follows:

Protections:read emily * //depot/elm_proj/... read * 195.42.39.17 //... write lisag * //depot/elm_proj/doc/... super edk * //...

`Protections:read emily * //depot/elm_proj/...` read * 195.42.39.17 //... write lisag * //depot/elm_proj/doc/... `super edk * //...`

The second and third permissions apply to Lisa: she is using a client workspace on the host specified in line 2, and she is the user specified on line 3. 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 a file that she only has read access to. She types p4 get //lisag/READ.ME, and this command succeeds; only read access is needed.

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 second permission applies to her, and she only has read privileges.

Permissions that Deny Access

A user can be denied access from particular files by prefacing the fourth field in a permission line with a minus sign ( - ). This is useful for giving most users a particular access level, while denying that same access level to only a few users.

Ed has used p4 protect to set up protections as follows:

Protections: read emily * //depot/elm_proj/... write * 195.3.21.* //... write joe * -//...write lisag * -//... write lisag * //depot/elm_proj/doc/... super edk * //...

Protections: `read emily * //depot/elm_proj/...` write * 195.3.21.* //... `write joe * -//...write lisag * -//...` write lisag * //depot/elm_proj/doc/... `super edk * //...`

The second permission seemingly grants write access to all users to all files in all depots, but this is overruled by later exclusionary protections for certain users:

· Joe can't do anything at all, ever: the third protection line denies him access to all files
in all depots from all hosts.

· The fourth line denies Lisa all write permissions, but this is counteracted by the later
fifth line, which gives her write permission in the Elm doc subdirectory.

Access Levels Required by Perforce Commands

The following table lists the minimum access level required to run each command.


Command	Access Level	Command	Access Level
`add`	write	job a	write
`branch` `¹`	write	jobs a	list
`branches`	list	label a	write
`change`	write	labels a	list
`changes` a	list	labelsync	write
`client`	list	lock	write
`clients` a	list	obliterate	super
`delete`	write	open	write
`depot` a	super	opened	list
`depots` a	list	print	read
`describe`	read	protect a	super
`describe -s`	list	refresh	read
`diff`	read	reopen	write
`diff2`	read	reresolve	write
`edit`	write	resolve	write
`files`	list	resolved	write
`filelog`	list	revert	write
`fix` a	write	review a	review
`fixes` a	list	reviews a	list
`get`	read	submit	write
`have`	list	unlock	write
`help`	none	user a	list
`info`	none	users a	list
`integrate` `²`	write	verify	super
integrated	list	where a	none

¹ This command doesn't operate on specific files. Thus, permission is granted to run these commands if the user has the specified access to at least one file in the depot.

² To run p4 integrate, the user needs write access on the target files and read access on the donor files.

Those commands that list files, such as p4 describe, will only list those files to which the user has at least list access.

[Top] [Prev] [Next]

[email protected]

System Administration:Protections

Field

Meaning

Access Level

Meaning

Command

Access Level

Command

Access Level

System Administration:
Protections