p4 protect

Synopsis

Syntax

Description

• Control which files particular users can access;

• Manage which commands particular users are allowed to use;

• Combine the two, allowing one user to write one set of files but only be able to read other files;

• Grant permissions to groups of users, as defined with p4 group;

• Limit access to particular IP addresses, so that only users at these IP addresses can run Perforce.

Form Fields

When exclusionary mappings are not used, 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. In this case, the order of the mappings is irrelevant.

When exclusionary mappings are used, order is relevant: the exclusionary mapping overrides any matching protections listed above it in the table. No matter what access level is being denied in the exclusionary protection, all the access levels for the matching users, files, and IP addresses are denied.

If you use exclusionary mappings to deny access to an area of the depot to members of group1, but grant access to the same area of the depot to members of group2, a user who is a member of both group1 and group2 is granted, not denied, access.

Options

-i	Read the form from standard input without invoking an editor.
-o	Write the form to standard output without invoking an editor.
g-opts	See the Global Options section.

Usage Notes

Can File Arguments Use Revision Specifier?	Can File Arguments Use Revision Range?	Minimal Access Level Required
No	No	super

• Each access level includes all the access levels below it, as illustrated in this chart:

• Access levels determine which commands you may use. The following table lists the minimum access level required for each command. For example, because p4 add requires at least open access, you can run p4 add if you have open, write, admin, or super access.

  Command	Access Level	Command	Access Level
  add	open	job b e	open
  admin	super	jobs a	list
  annotate	read	jobspec b	admin
  branch e	open	label a e	open
  branches	list	labels a b	list
  change e	open	labelsync	open
  changes a	list	lock	write
  client e	list	login	none
  clients	list	logout	none
  counter c	review	obliterate	admin
  counters	list	opened	list
  delete	open	passwd	list
  depot a b	super	print	read
  depots a	list	protect a	super
  describe	read	reopen	open
  describe -s	list	resolve	open
  diff	read	resolved	open
  diff2	read	revert	open
  dirs	list	review a	review
  edit	open	reviews a	list
  filelog	list	set	list
  files	list	submit	write
  fixes a	list	sync	read
  fstat	list	tag	open
  group a b	super	tickets	none
  groups a	list	triggers	super
  have	list	typemap	admin
  help	none	unlock e	open
  info	none	user a b	list
  integrate d	open	users a	list
  integrated	list	verify	admin
  		where a	none

a This command doesn't operate on specific files. Thus, permission is granted to run the command if the user has the specified access to at least one file in the depot.

b The -o flag to this command, which allows the form to be read but not edited, requires only list access.

c list access is required to view an existing counter's value; review access is required to change a counter's value or create a new counter.

d To run p4 integrate, the user needs open access on the target files and read access on the donor files.

e The -f flag to override existing metadata or other users' data requires admin access.

• When a new Perforce server is installed, anyone who wants to use Perforce is allowed to, and all Perforce users are superusers. The first time anyone runs p4 protect, the invoking user is made the superuser, and everyone else is given write permission on all files. Run p4 protect immediately after installation.

It is possible to deny yourself super access; if you accidentally deny yourself super access, you will subsequently be unable to run p4 protect. To get around this, remove the db.protect table under P4ROOT of the Perforce server.

• In the course of normal operation, you'll primarily grant users list, read, write, and super access levels. The open and review access levels are used less often.

• Those commands that list files, such as p4 describe, will only list those files to which the user has at least list access.

• Some commands (for instance, p4 change, when editing a previously submitted changelist) take a -f flag that requires admin or super access.

• The open access level gives the user permission to change files but not submit them to the depot. Use this when you're temporarily freezing a codeline, but don't want to stop your developers from working, or when you employ testers who are allowed to change code for their own use but aren't allowed to make permanent changes to the codeline.

• The review access level is meant for review daemons that need to access counter values.

• If you write a review daemon that requires both review and write access, but shouldn't have super access, grant the daemon both review and write access on two separate lines of the protections table.

• To limit or eliminate the use of the files on a particular server as a remote depot from a different server (as defined by p4 depot), create protections for user remote. Remote depots are always accessed by a virtual user named remote.

• For further information, consult the Protections chapter of the System Administrator's Guide.

Examples

Joe attempts a number of operations. His success or failure at each is described below:

Related Commands

To create or edit groups of users	p4 group
To list all user groups	p4 groups