How protections are implemented
This section describes the two-step algorithm that Helix server follows to implement protections.
Both passes proceed from the bottom line toward the top line.
|
First Pass
|
Determines whether the user is permitted to know if the file exists (and does not consider the user's access level). This search starts at the bottom line and looks for the first line encountered that matches the user name, host IP address, and file argument. If the first matching line found:
Helix server proceeds to the second pass. Otherwise, if the first matching
protection found is an exclusionary mapping, or if the top of the
protections table is reached without a matching protection being
found, the user has no permission to even list the file, and will
receive a message such as |
| Second Pass | If the first pass is successful, the second pass considers that user's access level. |
-
Example Interpreting the order of mappings in the protections table in the FIRST pass
Suppose the protections table is as follows:
write user * * //... read user edk * -//... read user edk * //depot/elm_proj/...
If Ed runs
p4 print //depot/file.c, Helix server examines the protections table bottom to top, and first encounters the last line. The files specified there don’t match the file that Ed wants to print, so this line is irrelevant. The second-to-last line is examined next. This line matches Ed’s user name, his IP address, and the file he wants to print. Because this line is an exclusionary mapping, Ed isn’t allowed to list the file. -
If the first pass is successful, Helix server makes a second pass at the protections table.
The second pass is the same as the first, except that access level is now taken into account.
If an inclusionary protection line is the first line encountered that matches the user name, IP address, and file argument, and has an access level greater than or equal to the access level required by the given command, the user is given permission to run the command.
If an exclusionary mapping is the first line encountered that matches according to the above criteria, or if the top of the protections table is reached without finding a matching protection, the user has no permission to run the command, and receives a message such as:
You don't have permission for this operation
Example Interpreting the order of mappings in the protections table involving the SECOND pass
Suppose that user
joeis a member of groupsdevgroupandbuggroup, 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 10.14.10.1p4 print //depot/misc/...Succeeds. The second line grants Joe
writeaccess on these files becausewriteaccess includesreadaccess, and this protection is not excluded by any lines of the lines above it.10.14.10.1p4 print //depot/proj/READMEFails. The third line removes all of Joe’s permissions on any files in this directory.
If -//depot/proj/... were the second line and //depot/... were the third line, the third line would have overridden the second line, and Joe would have succeeded.
192.168.100.123p4 print //depot/proj/READMESucceeds. Joe’s workstation is at an IP address from which he is granted this permission in the fourth line.
192.168.100.123p4 verify //depot/misc/...Fails. In the second pass, the algorithm considers access level. The p4 verify command requires
superaccess. Joe does not have this access level no matter what IP address he’s coming from.
Your search for returned result(s).






