September 20, 2011

The Perforce Access Control Model

What's New
Healthcare

Perforce's access control model has evolved significantly over the past few releases, and there's another change coming in the 2011.1 release this fall. I thought it'd be worth reviewing how you manage roles and access in Perforce, particularly since there's now some interplay between the traditional access control system and user types.

Access Levels

Speaking very broadly, Perforce has four main access levels.

  • Read access: the ability to see file history and content
  • Write access: the ability to modify and create content
  • Administer data access: the ability to modify certain parts of the repository's data
  • Administer server access: the ability to affect the state and operation of the server

If you're familiar with Perforce's protections table, you'll know that these four levels are roughly equivalent to the protections levels like read, write, admin, and super. There are other protection levels, of course, but they tend to be for very specific use cases.

Roles

Although Perforce doesn't officially have a role-based permission scheme, most of the time I think about the roles that people play when granting these access levels. Speaking again very broadly, traditionally Perforce has supported four roles.

  • Viewers who need to know about and see content
  • Writers who need to create and modify content
  • Application administrators who have some authority to modify history, content, and other data outside the scope of normal work
  • Server administrators who are responsible for backups, access control, and other super-user functions

Each of these traditional roles was a superset of the others. So if you were a server administrator, you could also do all the things that a writer could do. (Again, there are exceptions to this general principle, but it rarely made sense to grant write access while denying read access.)

The 2010.2 release introduced a service user, which is a special role intended for applications to authenticate themselves to the Perforce server. service users can perform a subset of super-user tasks so they can access enough data to perform replication and other activities. service users are very limited in what other activities they can perform. Replica servers use this account type to access the main Perforce server.

The 2011.1 release will introduce an operator user. This role is again a subset of the super-user role, intended for people like IT staff who need to help with backup and recovery, but have no need to actually see the data in the server. An operator can help with the daily care and feeding of a Perforce server.

A snapshot of access and roles

Here's a little table that provides a snapshot of the Perforce access levels and roles.

RolePurposeAccess levelsTypical commands
ViewerSee file history and contentlist,readfilelog,sync
WriterAdd or modify contentopen,writeedit,submit,integ
Application administratorHelp maintain some server dataadminverify,typemap,client -f
Server administratorTotal control over serversuperadmin checkpoint,protect,triggers
Service usersAuthentication between server and other processessuper (restricted)pull,login
OperatorSystem-level server maintenance with no data accesssuper (restricted)admin checkpoint,verify

Again, this information isn't comprehensive. The System Administrator's Guide has a complete list of the access levels required for each command. Information about the new operator users will be available with the 2011.1 release.

Adding new roles

The roles that Perforce defines out of the box work well enough in most cases. If you're a Perforce administrator, you're familiar with granting access to specific parts of the repository for different teams. With the service and operator users, we've taken a step towards defining very special purpose roles.

But what if you want to define a new type of role? As a really simple example, let's say that you want to restrict the delete command to project leads. The Writer role can make new content or change existing content, but you need to be in the new Curator role to remove content. Both roles need Perforce's write access level, so the protections table won't help us here. You can use a changelist trigger to prevent some users from deleting content, but that is a reactive measure.

A better solution is probably the Perforce Broker. With the broker, you could filter the delete command, restricting it to the Curator users. The broker gives you the flexibility to effectively create your own roles based on your policies.

What else do you need?

How well does Perforce access control work for you? Drop us a line and let us know what you think!