p4 protect

Control user access to files, directories, and commands.

These access rights are different from the graph depot permissions described at p4 grant-permission (graph).

Syntax

p4 [g-opts] protect
p4 [g-opts] protect -o
p4 [g-opts] protect -i
p4 [g-opts] protect --convert-p4admin-comments -o | -i

For Sub-protections:

p4 protect path
p4 protect -o path
p4 protect -i path

Syntax conventions

Description

Control user access to files, directories, and commands. These access rights are different from the graph depot permissions described at p4 grant-permission (graph).

p4 protect allows a user with super access to edit the protections table in a text form.

Use p4 protect to set Helix Core Server privileges in any of the following ways:

• Control which commands particular users can run.
• Grant access to groups of users, as defined with p4 group.
• Grant access to a particular path for a user or group.
• Use =read, =open, =write, and =branch in conjunction with an exclusionary mapping.
• Limit access to particular IP addresses.

It is common to specify any of the following access levels: list, read, write, owner, and super.

The admin, open, and review access levels are used less often.

For the minimum access level required to run each command, see Access levels required by Helix Server commands in the Helix Core Server Administrator Guide.

In general,

1. You grant an access level to a:
   • group (best practice), or
   • a user (if you cannot combine multiple users into a suitable group)
2. If finer-grained control is required, you can selectively deny one or more specific rights. To understand the effect of such "exclusionary mappings", see How protections are implemented in Helix Core Server Administrator Guide.

Permission levels and access rights

If the name of a permission level has the = prefix, it means the denial of a right.

Sub-protections

Sub-protections enable the user with super access to delegate management of parts of the protections table to non-super users or groups. To do so, create an entry with owner as the mode. Such entries must have a unique path without wildcards, except for a trailing ...

Users with super, or that have been granted owner for a path, can run the p4 protect command while specifying the granted path as an argument to access the sub-protections table for that path.

Any entries in the sub-protections table are appended to the effective protections table directly below the owner entry.

• If an owner entry is removed, so are any entries in the sub-protections table for that path.

• The owner permission only grants access to the sub-protections table at the specified path. It does not grant the specified user or group any permissions on that path.

• The owner can grant the owner admin permissions on that path.

• Neither owner nor super entries can be added to a sub-protections table, and the paths of any other entries paths must be within the scope of path of the sub-protections table.

See SubPath under Form Fields.

Stream spec permissions

Prior to release 2020.1, there were no protections modes specific to stream specs. The permissions for listing, reading, and editing stream specs were inferred from the corresponding filespec protections as follows:

• list permission in a depot granted the ability to run p4 streams to list streams in that depot.

• open or write permission on a file spec granted the ability to edit and save any stream spec whose stream root matches that file spec.

The 2020.1 release added protections modes that are specific to stream specs. By default, these permissions can exist in the protection table, but will not be used until the dm.protects.streamspec configurable has been set to 1. If the dm.protects.streamspec configurable is set to 1 and any stream spec permissions exist in the protection table, the pre-2020.1 permissions no longer apply and all users who are not admin or super require explicit stream spec permissions.

If you want to implement the legacy permissions with the stream spec permissions:

• Create a user group containing all users who require readstreamspec:
  
  

  readstreamspec group readgroup * //...

• Create another user group containing all users who require writestreamspec:
  

  writestreamspec group writegroup * //...


Form Fields

When you run p4 protect, Helix Core Server 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:

Comments

Protection tables can be difficult to interpret and debug so consider including comments.

• You can append comments at the end of a line using the ## symbols:

  write user *   10.1.1.1   //depot/test/...  ## my comment

• Or you can write a comment line by prefixing the line with the ## symbols:

  ## my comment
  write user *   10.1.1.1   //depot/test/...

Options

p4 protect --convert-p4admin-comments -o

Usage notes

Each permission level includes all the access levels below it:

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:

Protections:
    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:

• The =open exclusion prevents joe from opening any files for edit under //depot/build/
• The =write exclusion prevents joe from submitting any changes he might already have open under //depot/build/

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. 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.

To learn more, see Access levels required by Helix Core Server commands in the Helix Core Server Administrator Guide.

Related commands