The Perforce Decentralized Protect Daemon

About This Project

Content

The Decentralized Protect Daemon allows regular Perforce users to manage the permissions for parts of the perforce depot without granting them super user access. Each user can recursively delegate part of his responsibility to other users. The super users don't need to spend much time managing the perforce permissions.

Overview

The Decentralized Protect Daemon reads the permissions from files which may be submitted anywhere in the depot. These files are named p4.protect. Each p4.protect file contains the local permissions for that directory and all its subdirectories. The daemon combines all these files into one list which it applies using p4 protect -i.

A p4.protect file may only grant permissions using relative paths. The daemon uses the location of the p4.protect file to make the relative paths absolute.

Any user that can edit a p4.protect file, may grant him or herself all permissions for that subtree (including admin). Therefore, write permissions for the p4.protect files must be given explicitly. It is not possible to grant super user access by editing a p4.protect file.

Permissions set in one p4.protect file, can be overridden by another p4.protect file. This aspect heavily depends on the way Perforce protections are implemented. See this section in Chapter 4 of the Perforce System Administrator's Guide

There's one special file: the master.protect file. It can be located anywhere in the depot (the exact location can be set in a configuration variable). Only the master.protect file may grant superuser privileges and may have absolute paths.

The p4.protect file

A p4.protect file consists of up to three sections. Each section starts with a section header followed by permission lines, which must be indented. The section header may not be indented. Comment lines start with a # (possibly indented).

Example p4.protect file:

# Permissions for the Plonkels project
default:
   read     user    emily    *             ...
   write    group   devgrp   *             ...
enforce:
   write    user    *        195.3.24.0/24 -...
   write    user    joe      *             -intf/...
   write    user    lisag    *             -...
   write    user    lisag    *             doc/...
protect:
   write    user    jim      *             p4.protect

The following sections are supported:

  • default: Permissions in this section may apply to all files except the p4.protect files. These permissions may be overridden by p4.protect files submitted in a subdirectory of the current directory.
  • enforce: Permissions in this section may apply to all files except the p4.protect files. These permissions may override the default section of this p4.protect and the default and enforce sections of p4.protect files submitted in a subdirectory of the current directory.
  • protect: Permissions in this section may only apply to p4.protect files, including the file containing this section. These permissions may override the protect sections of p4.protect files submitted in a subdirectory of the current directory.

The syntax of a permission line is very similar to the Perforce syntax for permission lines. It uses the same five fields: Access Level, User/Group, Name, Host and Files. See Chapter 4 of the Perforce System Administrator's Guide for more details on these fields

For p4.protect files the following restrictions apply:

  • The Access Level cannot be super.
  • The Files field cannot start with a slash ('/'), i.e. it must be a relative path.

The master.protect file

The master.protect file has the same structure as the p4.protect file. It can be seen as the top-level p4.protect file. Its enforce and protect sections may override the permissions set in all p4.protect files.

The restrictions to the Access Level and File fields do not apply to the master.protect file. Thus, this file is the only place where super users are defined. All Files fields must contain absolute paths.

Downloads

  • todo

Project Background

The Decentralized Protect Daemon has been in use since 2003 at Ortec in the Netherlands. It is developed and maintained by Servaas Goossens (s goossens at ortec dot n l) and published under the GNU GPL in february 2008.

You're browsing a file stored as $Id: //guest/servaas_goossens/decentprotect/index.html#2 $