Setting Permissions with the Protect Table
Configuring the P4 Protect Table
The p4 protect table is accessed via the 'p4 protect' command.
Only p4 users with 'super' privileges (as set in the p4 protect table) can successfully run the 'p4 protect' command. When a new p4 server is started all users have super privileges until the first time a user runs 'p4 protect' and thereby creates a protection table that grants superuser access to that user, and reduces all other user's access level to write, so it is important to run this command directly after starting the server.
It is usually best practice to set protections based on groups rather than users, to keep the protect table manageable.
The protections table is stored in the db.protect file in the P4ROOT directory, the depot can be reverted to an unprotected state by deleting this file.
P4 Protect Syntax
Each line in the p4 protect table consists of the following fields:
<protection mode> <user/group indicator> <user/group name> <client host id> <depot file path pattern>
super user mdx * //...
Grants the user mdx super privileges from any client for all depots and paths on the server.
The User/Group field indicates whether the line applies to a user or a group. The User/Group Name field is the name of the user or group to which the line is applied.
The Client Host ID field specifies to which TCP/IP address the line applies to.
Exclusionary Lines
write user mdxuser * -//mdx_test/proj1/...
Exclusionary lines have a '-' preceding their path, this line will deny the specified access level to the specified user or group.
Protection Modes
Mode: The permission level or right being granted or denied. Each
permission level includes all the permissions above it, except
for 'review' and 'owner'. Each permission right only includes
the specific right and not all the lesser rights. Modes
preceded by '=' are rights; all other modes are levels.
list - users can see names but not contents of files;
users can see all non-file related metadata
(clients, users, changelists, jobs, etc.)
read - users can sync, diff, and print files
open - users can add, edit, delete, and integrate files
write - users can submit open files
admin - permits those administrative commands and command
options that don't affect the server's security
owner - allows access to the 'p4 protect' command, for
the specified path.
super - allows access to the 'p4 protect' command
review - allows access to the 'p4 review' command; implies
read access
=read - if this right is denied, users cannot sync, diff,
or print files
=branch - if this right is denied, users are not permitted
to use files as a source for 'p4 integrate'
=open - if this right is denied, users cannot open files
(add, edit, delete, integrate)
=write - if this right is denied, users cannot submit open
files
Protect Table Construction
Perforce reads the protection table from the bottom to the top and only stops when an exclusionary line applies specifically to the type, user, IP address, and file in question. The exclusionary line denies all previously granted access to that directory.
Allowing Read Access, but Denying Write Access
Protections: write group * * //... write group * * -//mdx_test/project1/... read group * * //mdx_test/project1/... super user mdx * //...
Reading from the bottom to the top:
- User mdx is granted 'super' level access to all depots on the server, protection checks for user mdx stop here
- All groups are granted 'read' level access to the files in 'mdx_test' depot under path '//mdx_test/project1/...', checks for read level access will continue until the top of the table or until an applicable exclusion is found
- All groups are denied 'write' level access to the files in 'mdx_test' depot under the path '//mdx_test/project1/...', any checks for write level access to this path will stop here
- All groups are granted 'write' level access to all files in the server in all depots, note write access to the '//mdx/project1/...' path is still denied by the line below.
Granting Administrator Access, but denying ability to change parts of the depot
Protections:
admin user cadmin * //...
=write user cadmin * -//mdx_test/project1/...
=open user cadmin * -//mdx_test/project1/...
The 'admin' level of permission implies the granting of all lesser permissions (list, read, open, write), so without the '=write' and '=open' lines user 'cadmin' would have these lesser permissions with the grading of the 'admin' right.
Reading from the bottom to the top:
- User cadmin is denied permission opening any files for edit in the '//mdx_test/project1/...' path
- User cadmin is denied permission to submit any files they may already have open under the same path
- User cadmin is granted admin permission to all depots on the server
Some important points:
- Perforce reads the protection table from bottom to top, it will stop if it finds an exclusionary mapping that applies to the path its searching for, or once it reaches the top of the table
- It is best practice to place super user specifications at the bottom of the protect table to avoid locking out super users with exclusionary mappings (preceded with a '-').
Displaying a User's Protections
The 'p4 protects' command will show the protections that apply to a particular user:
p4 protects -u username (use 'p4 protects -g groupname' to display the protections that apply to a group)
Will result in output similar to
list group all_users * -//... write user username * //depot/foo_project/...
Disallowing the 'remote' user
By default all files on a Perforce server can be accessed remotely by user 'remote' in read-only mode. It is recommended to add the following line to the p4 protect table to disallow this access. Access can be re-granted as needed.
list user remote * -//...
Efficiency in p4 protect definition - Library Level is Best
When combined with Perforce IPLM and a systematic repo path definition methodology it is possible to realize some efficiencies in defining and managing the p4 protect table. A typical repository path in the 'mdx_test' Perforce repository for the tutorial.padring@.TRUNK IP Line would be:
//mdx_test/tutorial/padring/TRUNK
The growth of the size of the p4 protect table can be greatly reduced by setting p4 permissions at the Library level (//mdx_test/tutorial) rather than at the IP or the Line level. Separate permissions for each individual IP or line is generally not necessary.