I’ve been trying back and forth to get CS-RCS Pro, a version control suite, to work on Windows Vista.
I like CS-RCS Pro for a number of reasons:
- Files stored in CS-RCS Pro are kept in a simple format, open and well-documented. As a result, if I ever have to move away from CS-RCS Pro (say, for instance, if they go out of business, or stop supporting it), I stand a good chance of reconstructing my versioning information completely in whatever product I move to, if only by re-creating files at each epoch and then checking them in to the new tool.
- CS-RCS Pro integrates with Visual Studio. I can check files in and out while I’m editing them.
- CS-RCS Pro integrates with Explorer, as a Shell Extension, so that you can right-click on source files, and check them in from there.
- Of course, most important is that for single users, it’s free.
But that last point is the cause of a big problem.
Here’s the sequence I have to deal with:
- I have the single-user version of CS-RCS Pro.
- I use best practices for development of secure applications, particularly as regards running my software and my development tools as a restricted user unless it is strictly necessary to become an admin to test admin-level features, or to install / uninstall software or services, or to debug code that is running a different user context from my own.
- CS-RCS Pro insists that the user who installs it is also the user who runs it.
- CS-RCS Pro must be installed by an administrator.
I had originally intended to follow the appropriate installation practice for an enterprise application – that it should be installed by a recognised administrator, and then any post-install setup to customise for the end-user would be carried out by that end-user for themselves.
This didn’t work, as CS-RCS Pro configured the version control tree to be used by the administrative user, making it impossible for my restricted user to access the files.
I tried simply editing the ownerships and ACLs – that didn’t work – and then to additionally edit the configuration files, where it mentioned the name of my administrative user. That worked for a short while, but I noticed that every time I used MSTSC – Remote Console – also known as the Terminal Services Client – to access the system, the shell extension that CS-RCS Pro installs took up 100% CPU, and required that I restart Explorer. There are still a few applications that don’t work well when you kill Explorer from underneath them, and so this was somewhat of an untenable position.
Besides, this was an awful lot of effort to go through in order to get version control going.
Finally, it hit me how I should do this properly. It’s not clean and it’s not clever, and ComponentSoftware, the folks behind CS-RCS Pro, should consider how to change their installer to avoid this issue.
The simple five-step process is as follows – let’s say Wayne, an administrator, wants to install the software for Sharon, a restricted user:
- Wayne adds Sharon to the Local Administrators group on the machine to which Wayne will be installing CS-RCS Pro.
- Wayne logs on as Sharon (*)
- Wayne installs the application.
- Wayne logs off Sharon’s account.
- Wayne removes Sharon from the Local Administrators group.
(*) Note that asterisk – that’s the troubling part. Actually, step 1 is troubling too, but only because Sharon may have other processes trying to log in with elevated rights, should they ever be granted.
Step 2 requires either that Wayne allows his user, restricted though she is meant to be, to log on as an administrator – what if she quickly runs some tool that you don’t want her to run?
Okay, so you drag her away from the console immediately after she types her password – but what if she’s got startup items to add an administrative user on her behalf, or simply to stay in memory (as a service, say) and run with those enhanced privileges, to allow exploit later?
Alright, so what’s the safest way? The only good way I can think of is this:
- Wayne resets Sharon’s password.
- Wayne adds Sharon’s account to Local Administrators. Note that Sharon can’t log on at this point.
- From a command prompt in Wayne’s restricted user account, Wayne uses the runas command to execute the installation script in Sharon’s new administrative context. Runas reduces, and possibly eliminates, the chance that this administrative context will have the ability to run Sharon’s own code (unless the installation script does so).
- Wayne removes Sharon from the Local Administrators account.
- Wayne sets Sharon’s account to force a password change after the next logon.
- Wayne tells Sharon her new password.
- If this is not a domain environment, Sharon must change her password back to what it used to be, so that it is possible for her to access her protected data.
Some of you are probably reading this and wondering why I bother – after all, in many environments, developers insist on running as administrator all the time, because their development tools don’t support anything else.
Well, it’s time your developers – and their tools – grew up. Yes, I can quote, just as any other developer can, a number of cases where administrative access is required – although many developers actually get this wrong. You can run Visual Studio 2005 as a non-administrator. You can debug your own code running in your own logon session as a non-administrator.
Developers are very often the only people to run some sections of the code that they build, until it reaches the hands of the users. As such, developers need to spend as much time as possible, when they run their code, working in the same kind of user context as their users will have.
In general, developers should follow the same principle as other administrators – their day-to-day tasks (e-mail, web browsing, and yes, development) should be done in restricted user accounts; administrative user accounts should be available, but their use should be restricted to those operations which absolutely require administrative access, and those operations should be reviewed often enough to ensure that they need administrative access. Tools and environments grow and change, and a tool which yesterday required administrative access may run tomorrow without. LogonUser, for instance, used to require complete system access – today it can be called by any user.