Perforce - Access Control and Security

Access Control and Security

The Perforce server stores file content in a master repository that, when properly installed, is inaccessible to users. User access to files is controlled by one or more Perforce superusers. A range of file access protection levels can be granted. Protections can be set for repository file paths, users, groups, and IP address subnets. The server can maintain an audit log of client access events for SOX and other compliance requirements.

User authentication is controlled by the Perforce system administrator. Password strength is configurable; ticket-based authentication can be configured as well. Triggers (custom scripts or programs that run at predefined events) can be set on many but not all Perforce user commands and used to extend user authentication (with LDAP or SSO, for example), to block or allow user commands, and to constrain or normalize file modifications. Triggers are run by the Perforce server and do not have access to client machines or workspaces.

Perforce, like most version control systems, does not encrypt file content in the master repository or on user machines. Perforce versions prior to 2012.1 cannot encrypt file content sent over the network. A tunneling protocol (like VPN or SSH) must be used to secure network transfers with those versions.

The Perforce client completely trusts the server, including writing arbitrary files anywhere in the local filesystem, and therefore running arbitrary code from the server. That means the server has complete control over the client user's account, including reading and writing and sending all non-source code files of the user. In environments where the Perforce server is managed by a third party, this poses a significant threat to the client's security and privacy.