The security of a Perforce Server is always important for any administrator. With a vanilla Perforce install, the aim is to make things easy for you to get started—but that means things may be a bit more ‘open’ than you’d like them to be. So, what can you do to make your server more secure?
Let’s Get Some Security
First things first. Let’s make sure that your users need a password to log in to Perforce and access the server. The Perforce Server’s password policy is managed through its ‘security’ configurable. To ensure that a user must have a password set for the account, set ‘security’ to ‘1’ or higher. With this in place, the next time a user attempts to access the Perforce Server it will require setting a password.
As I mentioned, you need to set 'security' to '1' or higher (currently, '3' is the maximum value) and as it is increased, the method for user authentication becomes stricter. For example, at level ‘1’ users can set their password in the environment variable P4PASSWD; however, at level ‘3’ users can only use ‘p4 login’ to authenticate.
In 2010.2, 'p4 configure' was introduced to the Perforce Server, which you can use to dynamically set 'security'. So, for security to take effect immediately, an adminstrator can just run:
p4 configure set security=3
Although the aim is to get to ‘security’ level ‘3’, it might not be easy to do so and you may need to do a phased rollout. For example, you could start by notifying your user community that they’ll need to set a password, which you can check using:
p4 –Ztag users
When you are ready to you could start with ‘security=1’. At this point, users will need to set a password before they can continue, but it also gives you the opportunity to sort any user names before you attempt to link your Perforce Server with an authentication server.
Customer sites often already have an authentication server, such as Active Directory (AD) or LDAP. If you do, then you already have a service on your site to manage user authentication, and Perforce can leverage this. All you need to do is set up an ‘auth-check’ trigger on the Perforce Server to link to your auth server. Now when users log in to Perforce, they can use their AD/LDAP password. In Perforce 2011.1, you can now also log in with a password that’s up to 1,024 bytes. So, if you couldn’t use your external auth server due to password length restrictions in Perforce, think again. Hopefully the new limit is more than enough.
Get Your Users Organized
‘Groups’ are a brilliant feature of Perforce; they allow administrators to organize their users. Once in groups, you can set owners (introduced in 2007.3), so team leaders can manage the group specification as users move around, leave, and join. You can also set limits for groups, such as how long a user’s ticket is valid for (‘Timeout’) and, as of 2010.2, how long the password is valid for (‘PasswordTimeout’). So, if you’re using Perforce to authenticate your users, you can ensure that their passwords are changed on a regular basis by setting ‘PasswordTimeout’ in the group.
Don’t Forget the Server’s Protection Table
Probably the most useful tool when securing a Perforce Server is its protections table. I’m not going to delve into great detail here (as I’m hoping you already have one set up), but I think it is useful to mention the often-overlooked ‘host restriction’. Each entry in the protections table can be restricted to a particular host or subnet.
Why would this be useful? One use case is to ensure that background users (which may be using a long-life ticket) can only be used from a particular machine. For example, if you have a set of scripts that run on the Perforce Server machine that read the content of your server with the account ‘bg_user’, you could add the following entry to the protections table for that user:
read user bg_user 127.0.0.1 //depot/path/…
But this isn’t the only reason; you could use it to ensure that your users are connecting from a known host, or to ensure that external users only connect through a Perforce Proxy.
What’s more, the field doesn’t have to be restricted to a specific host. You could use wildcards (like ‘192.168.*’ or ‘proxy-*’) or CIDR notation (‘10.1.0.0/16’).
I thought I’d take this opportunity to mention a new feature introduced in 2010.2: ‘public’ and ‘private’ changelists. Previously, if you had sensitive data in a server’s changelist that others shouldn’t be allowed to see, you would have to submit it to a separate server.
Public changelists are just like your good old changelists from before, so if you have access to the Perforce Server then you can see its contents. If the changelist contains sensitive data, users can now mark the changelist as ‘private’ when they submit. Other users won’t even know that they exist unless they have ‘list’ access to one of the files.
Jayesh Mistry joined Perforce fresh from university in January 2005 as a Graduate Technical Support Engineer. After many years supporting our customers, he changed roles in April 2011 and joined the Perforce Training and Consulting team. His role encompasses training and consulting services, as well as working alongside the support team in the UK. In his spare time he likes to develop tools like P4Ruby and Perfsplit++.