Control users' access to files, directories, and commands
Use p4 protect to control Perforce permissions. You can use p4 protect to
Perforce provides six levels of access. The access levels are:
Access Level | What the User Can Do |
---|---|
list | The user can access all the Perforce metadata, but has no access to file contents. She can run all the commands that describe Perforce objects, such as p4 files, p4 client, p4 job, p4 describe, p4 branch, etc. |
read | The user can do everything she can do with list access, and she can run all the commands that allows her to read files, such as p4 print, p4 diff, p4 sync, etc. |
open | This gives the user permission to do everything she can do with read access, and gives her permission to p4 add, p4 edit, and p4 delete files. However, she is not allowed to lock files or submit files to the depot. |
write | The user can do all of the above, and she can write files with p4 submit and lock them with p4 lock. |
review | This permission is meant for external programs that access Perforce. It gives the external programs permission to do anything that list and read can do, and grants permission to run p4 review and p4 counter. It does not include open or write access. |
super | Includes all of the above, plus access to the superuser commands such as p4 verify, p4 obliterate, p4 jobspec, etc. (In Perforce's most technical terminology, this is called the whole enchilada). |
When you run p4 protect , Perforce displays a form with a single field, Protections:. Each permission is specified in its own indented line under the Protections: header. Each line has five values; these values are:
Column | Description |
---|---|
Access Level | One of the access levels list, read, open, write, review, or super, as defined above. |
User or Group | Does this protection apply to a user or a group? The value of this field must be user or group. |
Group Name or User Name | The name of the user or the name of the group, as defined by p4 group. To grant this permission to all users, use the * wildcard. |
Host | The IP address. Use * for all IP addresses. |
Depot File Path |
The depot file path this permission is granted on, in Perforce depot syntax. The file specification can contain Perforce wildcards. To exclude this mapping from the permission set, use a dash (-) as the first character of this value. |
When exclusionary mappings are not used, a user will be granted the highest permission level listed in the union of all the mappings that match the user, the user's IP address, and the files the user is trying to access. In this case, the order of the mappings is irrelevant.
When exclusionary mappings are used, order is relevant: the exclusionary mapping override any matching protections listed above it in the table. No matter which access level is being denied in the exclusionary protection, all the access levels for the matching users, files, and IP addresses are denied.
-i | Read the form from standard input without invoking an editor |
-o | Write the form to standard output without invoking an editor |
g_opts | See global options section. |
Can File Arg Use Revision Specifier? |
Can File Arg Use Revision Range? |
Minimal Access Level Required |
---|---|---|
No | No | super |
Command | Access Level | Command | Access Level | |
---|---|---|---|---|
add | open | integrated | list | |
branch 1 2 | open | job 2 | open | |
branches | list | jobs 1 | list | |
change | open | jobspec 1 2 | super | |
changes | list | label | open | |
client 2 | list | labels | list | |
clients | list | labelsync | open | |
counter | review | lock | write | |
counters | list | obliterate | super | |
delete | open | opened | list | |
depot 1 2 | super | passwd | list | |
depots 1 | list | read | ||
describe | read | protect 2 | super | |
describe -s | list | reopen | open | |
diff | read | resolve | open | |
diff2 | read | resolved | open | |
edit | open | revert | open | |
filelog | list | review 2 | review | |
files | list | reviews 2 | list | |
fix 1 | open | set | (none) | |
fixes 1 | list | submit | write | |
fstat | list | sync | read | |
group 1 2 | super | triggers | super | |
groups 1 | list | unlock | open | |
have | list | user 1 2 | list | |
help | (none) | users 1 | list | |
info | (none) | verify | review | |
integrate 3 | open | where 1 | (none) |
Suppose that user joe is a member of groups devgroup and buggroup, as set by p4 group, and the protections table reads as follows:
super user bill * //...
write group devgroup * //depot/...
write group buggroup * -//depot/proj/...
write user joe 100.*.100 //...
Joe attempts a number of operations. His success or failure at each is described below:
From IP address... | Joe tries... | Does he succeed or fail? |
---|---|---|
37.100.27.54 | p4 print //depot/misc/... | Succeeds. The second line grants Joe write access on these files; write access includes read access, and this protection isn't excluded by any subsequent lines. |
27.100.27.43 | p4 print //depot/proj/README | Fails. The third line removes all of Joe's permissions on any files in this directory. (If the second protection and the third protection were switched, then a subsequent protection would override this one, and Joe would succeed). |
100.83.82.100 | p4 print //depot/proj/README | Succeeds. Joe is sitting at an IP address from which he is granted this permission in the fourth line. |
100.83.82.100 | p4 verify //depot/misc/... | Fails. p4 verify requires super access; Joe doesn't have this access level no matter which IP address he's at. |