p4 protect
Synopsis
Control users' access to files, directories, and commands.
Syntax
p4 [g-opts
] protect
p4 [g-opts
] protect
-o
p4 [g-opts
] protect
--convert-p4admin-comments -o | -i
Description
For a new Perforce installation, anyone who wants to use Perforce is
allowed to connect to the service, and all Perforce users are
superusers. The first time anyone runs p4 protect
, the invoking
user is made the superuser, and everyone else is given write
permission on all files. Run p4 protect
immediately after
installation.
Use p4 protect
to control Perforce permissions. You can use
p4 protect
to do the following:
- Control which commands and/or files particular users can access
- Grant permissions to groups of users, as defined with
p4 group
- Grant access to the
p4 protect
command for a particular path, to a user or group - Grant or deny specific access rights to users by using the
=read
,=open
,=write
, and=branch
rights, without having to re-grant lesser permissions - Limit access to particular IP addresses, so that only users at the specified IP addresses can run Perforce.
The command provides three syntax variants:
- The first variant allows you to edit the protections table in a text form.
- The second variant writes the protection table to standard output
- The third variant reads the protection table from standard input. You can also use this variant to convert comments in the p4admin-generated protection table. For more information, see Comments.
In the course of normal operation, you’ll primarily grant users list
,
read
, write
, owner
, and super
access levels. The open
and review
access levels are used less often.
In general, you typically grant an access level to a user or group, after which, if finer-grained control is required, you can selectively deny one or more specific rights.
For detailed information, see the "Security" chapter of the Helix Versioning Engine Administrator Guide: Fundamentals.
Permission levels and access rights are described in the table below:
Permission Level / Right | What the User Can Do |
---|---|
|
The user can access all Perforce metadata, but has no access to file
contents. The user can run all the commands that describe Perforce
objects, such as Those commands that list files, such as |
|
The user can do everything permitted with |
|
If this right is denied, users cannot use |
|
This gives the user permission to do everything she can do with The |
|
If this right is denied, users cannot open files with |
|
The user can do all of the above, and can also write files with
|
|
If this right is denied, users cannot submit open files. |
|
If this right is denied, users cannot use files as a source for
|
|
This permission is meant for external programs that access Perforce.
It gives the external programs permission to do anything that |
|
Includes all of the above, including administrative commands that override changes to metadata, but do not affect service operation. These include |
|
Includes all of the above, plus access to the superuser commands such
as |
|
Use this permission to assign permission to a specific user or group to run
|
Form Fields
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, and uses the following five values
to define protections:
Column | Description |
---|---|
Access Level or Mode |
One of the access levels |
User or Group |
Specifies whether this protection applies to a |
Group Name or User Name |
The name of the user or the name of the group, as defined by
|
Host |
The IP address of the client host. IPv6 addresses and IPv4 addresses
are also supported. You can use the If you use the How the system forms host addresses depends on the setting of the
Setting the |
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 ( If a depot is excluded, the user denied access will no longer see the
depot in the output of |
Exclusionary mappings
When exclusionary mappings are not used, a user is 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 overrides any matching protections listed above it in the table. No matter what access level is being denied in the exclusionary protection, all the access levels for the matching users, files, and IP addresses are denied.
If you use exclusionary mappings to deny access to an area of the depot
to members of group1
, but grant access to the same area of the depot
to members of group2
, a user who is a member of both group1
and
group2
is either granted or denied access based on whichever line
appears last in the protections table.
Comments
Protection tables can be difficult to interpret and debug. Including comments can make this work much easier.
-
You can append comments at the end of a line using the ## symbols:
write user * 10.1.1.1 //depot/test/... ## robinson crusoe
-
Or you can write a comment line by prefixing the line with the ## symbols:
## robinson crusoe write user * 10.1.1.1 //depot/test/...
Warning
Comments you have created using the P4Admin tool are not compatible with
comments created using the 2016.1 version of p4 protect
. You can
use the following command to convert a file containing comments created
with P4Admin into a file containing p4 protect
type comments:
$ p4 protect --convert-p4admin-comments -o
Then save the resulting file.
Once you have converted the comments, you must continue to define and
manage protections using p4 protect
and can no longer use
P4Admin to do so because this tool is unable to parse p4 protect
comments.
Options
|
Read the form from standard input without invoking an editor. |
|
Write the form to standard output without invoking an editor. |
|
Converts an existing protections form (and comments) created using
P4Admin tool, to a form that can be used by |
|
See “Global Options”. |
Usage Notes
Can File Arguments Use Revision Specifier? | Can File Arguments Use Revision Range? | Minimal Access Level Required |
---|---|---|
No |
No |
|
Each permission level includes all the access levels below it, as illustrated in this chart:
The specific rights of =read
, =open
, =write
, and =branch
can be
used to override the automatic inclusion of lower access levels. This
makes it possible to deny individual rights without having to then
re-grant lesser rights.
For example, if you want administrators to have the ability to run administrative commands, but to deny them the ability to make changes in certain parts of the depot, you could set up a permissions table as follows:
admin user joe * //... =write user joe * -//depot/build/... =open user joe * -//depot/build/...
In this example, user joe
can perform administrative functions, and
this permission applies to all depots in the system. Because the admin
permission level also implies the granting of all lower access levels,
joe
can also write, open, read and list files anywhere in the system,
including //depot/build/
. To protect the build area, the =write
and
=open
exclusionary lines are added to the table. User joe
is
prevented from opening any files for edit in the build area. He is also
prevented from submitting any changes in this area he may already have
open. He can continue to create and modify files, but only if those
files are outside of the protected
//depot/build/...
area.
To limit or eliminate the use of the files on a particular server as a
remote depot from another server (as defined by p4
depot
), create protections for user remote
(or for the service
user by which the other server authenticates itself). Remote depots are
accessed either by the service user associated with the user’s Perforce
service, or by a virtual user named remote
.
Access levels determine which commands you can use.
The following table lists the minimum access level required for each
command. For example, because p4 add
requires at least
open
access, you can run p4 add
if you have open
,
write
, admin
, or super
access.
Some commands (for instance, p4 change, when editing a previously
submitted changelist) take a -f
option that requires admin or super
access.
Command | Access Level | Notes |
---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The |
|
|
The |
|
|
|
|
|
The |
|
|
This command does not operate on specific files. Permission is granted to run the command if the user has the specified access to at least one file in any depot. |
|
|
The |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The |
|
|
This command does not operate on specific files. Permission is granted to run the command if the user has the specified access to at least one file in any depot. |
|
|
The |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This command does not operate on specific files. Permission is granted to run the command if the user has the specified access to at least one file in any depot. |
|
|
|
|
|
|
|
|
|
|
|
The The The |
|
|
This command does not operate on specific files. Permission is granted to run the command if the user has the specified access to at least one file in any depot. |
|
|
|
|
|
|
|
|
|
|
|
The user must have |
|
|
|
|
|
|
|
|
|
|
|
The The |
|
|
This command does not operate on specific files. Permission is granted to run the command if the user has the specified access to at least one file in any depot. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This command does not operate on specific files. Permission is granted to run the command if the user has the specified access to at least one file in any depot. The |
|
|
This command does not operate on specific files. Permission is granted to run the command if the user has the specified access to at least one file in any depot. |
|
|
|
|
|
The |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Must be connected to a Perforce Proxy |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This command does not operate on specific files. Permission is granted to run the command if the user has the specified access to at least one file in any depot. |
|
|
This command does not operate on specific files. Permission is granted to run the command if the user has the specified access to at least one file in any depot. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The |
|
|
|
|
|
The |
|
|
|
|
|
|
|
|
This command does not operate on specific files. Permission is granted to run the command if the user has the specified access to at least one file in any depot. The |
|
|
This command does not operate on specific files. Permission is granted to run the command if the user has the specified access to at least one file in any depot. If the |
|
|
|
|
|
This command does not operate on specific files. Permission is granted to run the command if the user has the specified access to at least one file in any depot. |
Examples
Suppose that user joe
is a member of groups devgroup
and buggroup
,
as set by p4 group
, the organization is using only
IPv4 connections, and the protections table reads as follows:
super user bill * //... write group devgroup * //depot/... write group buggroup * -//depot/proj/... write user joe 192.168.100.0/24 //...
Joe attempts a number of operations. His success or failure at each is described below:
From IP address… | Joe tries… | Results |
---|---|---|
|
p4 print //depot/misc/... |
Succeeds. The second line grants Joe |
|
|
Fails. The third line removes all of Joe’s permissions on any files in this directory. (If the second protection and the third protection had been switched, then the subsequent protection would have overridden this one, and Joe would have succeeded). |
|
|
Succeeds. Joe’s workstation is at an IP address from which he is granted this permission in the fourth line. |
|
p4 verify //depot/misc/... |
Fails. |