How protections are implemented
This topic assumes you have read p4 protect in 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 |
---|---|---|
|
|
Succeeds because Dev1 can write anywhere in the depot except the proj area. |
|
|
Fails because the the exclusionary mapping of -//depot/proj/... removes all of Maria’s permissions on any files in this directory. |
|
|
Succeeds because at this IP address, Maria's write permission implies the ability to print. The last line that matches "wins". |
|
|
Fails because the p4
verify command requires |
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.
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 |
---|---|
|
|
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 |