How protections are implemented

This topic assumes you have read p4 protect in the Helix Core Command-Line (P4) Reference.

For any given command by any user, the server reads the protections table for a line matching user or group, IP address, file path, and access level.

If more than one line matches, the last line "wins".

The table contains the following columns:

  • access level, such as write or super
  • group or user - to keep the table short, we recommend combining users into groups
  • name of that group or user - although * is allowed, we recommend using specific groups
  • IP Address for the server (host), or * for any IP Address
  • Comments, which have the ## prefix

A protections table might look like this:

write   group   Dev1  *                       //depot/...
list    group   Dev1  *                       -//depot/proj/...  ## exclusionary mapping
write   user    Maria 192.168.100.0/24        //...
super   user    Alice *                       //...  ## put super user at the bottom

Suppose that user Maria is a member of Dev1, the organization is using IPv4 connections, and Maria attempts four operations:

From IP address…​ Maria tries…​ Result

10.14.10.1

p4 print //depot/misc/...

Succeeds because Dev1 can write anywhere in the depot except the proj area.

10.14.10.1

p4 print //depot/proj/README

Fails because the exclusionary mapping of -//depot/proj/... removes all of Maria’s permissions on any files in this directory.

192.168.100.1

p4 print //depot/proj/README

Succeeds because at this IP address, Maria's write permission implies the ability to print. The last line that matches "wins".

192.168.100.1

p4 verify //depot/misc/...

Fails because the p4 verify command requires super access. Maria only has write access.

Without an exclusionary mapping, the most permissive line rules

An exclusionary mapping begins with the minus sign (-). For example, -//depot/dev/productA/...

Suppose user Maria is a member of Dev1 and Dev2, and the protections table contains no exclusionary mapping:

write       group       Dev2    *    //depot/dev/...
read        group       Dev1    *    //depot/dev/productA/...
write       group       Dev1    *    //depot/elm_proj/...

Maria can run p4 edit //depot/dev/productA/readme.txt because all members of the Dev2 group can do so.

Note

If at least one group to which the user belongs can run the command, that user can run the command.

Exclusion overrides prior inclusion

Suppose the protections table contains an exclusionary mapping, -//depot/dev/productA/..., that prevents Maria from editing files in the productA directory:

write   group   Dev1   *   //depot/dev/...            ## Maria is a member of Dev1
list    group   Dev1   *   -//depot/dev/productA/...  ## exclusionary mapping overrides the line above
super   group   super-users   *   //...               ## Maria is NOT a member

If Maria attempts to run p4 edit //depot/dev/productA/readme.txt, she cannot because she is excluded from /depot/dev/productA/... and no lower line overrides that exclusion.

Exclusionary mappings and admin

In this case,

write   group   Dev1   *   //depot/dev/...            
write    group   Dev1   *   -//depot/dev/productA/... 
super   group   super-users   *   //...               

the members of Dev1 have no access to productA.

However, in this case,

admin   group  Admins  *   //depot/...          
write   group  Admins   *   -//depot/dev/productA/... 
super   group  super-users   *   //...               

although the members of Admins cannot edit the files in productA, they can run administrative commands, such as p4 changes.

Consider whether any exclusionary mappings are present

If exclusionary mappings are NOT present

If exclusionary mappings ARE present

  • 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.
  • A matching exclusionary mapping overrides any matching protections listed above it in the table.

Exclusionary mapping and =

- before the file path:
write   group   Dev1    *   //depot/dev/...          
list   group    Rome    *   -//depot/dev/prodA/...   ## exclusion of list implies no read, no write, etc.
read    group   Rome    *   //depot/dev/prodA/...   ## Rome can only read this one path
write   group   Dev2    *   //depot/elm_proj/...      
super   user    Anne    *   //...                    
- before the file path and = before the access level
write   group   Dev1    *   //depot/dev/...            
=read  group    Rome    *  -//depot/dev/prodA/...   ## Rome cannot read this one path
write   group   Dev2    *   //depot/elm_proj/...       
super   user    Anne    *   //...                      

See also the "Permission levels and access rights" in the description of p4 protect in the Helix Core Command-Line (P4) Reference.

Access levels and =

If the line is ... ... for the specified user, IP address, and file path ...
read group Dev1 * -//depot/dev/prodA/... denies read and its lesser permissions
=read group Dev1 * -//depot/dev/prodA/... denies read but allows its lesser permissions
open group Dev1 * -//depot/dev/prodA/... denies open and its lesser permissions
=open group Dev1 * -//depot/dev/prodA/... denies open but allows its lesser permissions
write group Dev1 * -//depot/dev/prodA/... denies write and its lesser permissions
=write group Dev1 * -//depot/dev/prodA/... denies write but allows its lesser permissions
Unlike read, open, and write, =branch always has the =
=branch group Dev1 * -//depot/dev/prodA/... denial of integrate to that path