Fog Creek Software
Discussion Board




Locked-down programming.

How much should a programmer's computer be locked down ? Should they have administrator privilege on their work computer ?

Here's a little background to these two questions :
I have been told I will have to work in a SOE (Secure Operating Environment) where :
- You can't change the screen saver or desktop background (oh noes!)
- there's no access to the control panel
- you can't start or stop services
- no Add/Remove programs (ouch!)
- no ODBC administration
- The C drive has almost no write access except for the temp directory and the My documents folder.

Francois
Friday, February 27, 2004

Somebody other than me with some experience in the matter should comment. I've been trying to get to the point where I don't have to be logged on as Administrator all day long but there are so many nasty apps like Listen/Rhapsody which I use all day long and which require admin privs...

Actually now I see XP will let me run one program as admin while other programs run with lowered privs, so maybe I can get there one day.

Joel Spolsky
Fog Creek Software
Friday, February 27, 2004

It is difficult and tedious to develop as a non-Administrator.  There's an MSDN article out there somewhere about leveraging the "Run As" feature in XP/2000 to do this, which I need to study because everything I try I get really frustrated and give up.

You have to have at least this ability (whether to run as a genuine admin or a carefully-tweaked user with sufficient rights); to develop on a machine where you have no control over services, no software installation functionality, no ODBC administration, no non-trivial file-system access... is to develop applications that do little of interest or value.

Jim Causey
Friday, February 27, 2004

This weblog entry:

http://weblogs.asp.net/rhurlbut/archive/2003/12/10/42678.aspx

Lists a couple of good articles:

http://www.develop.com/kbrown/book/html/howto_runasnonadmin.html

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/html/tchDevelopingSoftwareInVisualStudioNETWithNon-AdministrativePrivileges.asp

Jim Causey
Friday, February 27, 2004

- You can't change the screen saver or desktop background (oh noes!)

Dumb.

- there's no access to the control panel

Dumb.  What if they decide to set your CRT refresh rate to 60 hz and set it to 640x480 resolution?

- you can't start or stop services

Not too much of a problem.

- no Add/Remove programs (ouch!)

Dumb.  Can not be allowed to experiment with new version of your development platform without losing your current version?

- no ODBC administration

Not too much of a problem.  ODBC should be banned.

- The C drive has almost no write access except for the temp directory and the My documents folder.

Dumb.  Programs require access to "Documents and Settings" folder, among their own preferences in order to write stuff.  Just lock down /WINNT.

* * *

Seriously, they're dumb, especially when you need to test your programs using common user environments.

Just require people to lock their screen when they leave their computer.

-T.J.

T.J.
Friday, February 27, 2004

We recently were notified that we'll be upgrading from NT to XP Pro at work.  So the sheet went around work (why do people send Excel spreadsheets listing everyone's settings when each person replies individually?) asking about processor speed, memory, etc.  I gather they're just going to swap out the tower rather than reimage the drive remotely (because manual labor is good).

One of the rows says "Administrator Access".  YES!  I don't know how everyone else deals with not having this, it was the first thing I requested when I was hired.  I've installed my own versioning system, my own bug tracking system, and a ton of useful utilities that I coudn't otherwise perform.

IT should understand that programmers require tools and they often know how to fix their own computers.  So let me.

Lou
Friday, February 27, 2004

Developers often need to perform high-privilege operations, like debugging system processes or changing security policy. Today it's pretty hard to run a dev box without being local admin.

But we're trying.  One of our goals for future releases of Visual Studio is to increase the number of scenarios in which routine use of the tool does not require admin privilege. 

Eric Lippert
Friday, February 27, 2004

Of course, I could do a LOT of things without knowing ROOT under UNIX.

But then even there -- I can not administer DataStage without having SUDO access for some specific commands.  Well, it was either that or beg UNIX admins to do it for us.  They're wonderful but one wonders how wonderful they can be at 3am...

-T.J.

T.J.
Friday, February 27, 2004

I have developed in both kinds of environments (one where there is strict security and no admin rights and another where you can pretty much anything with your machine) Ihave found that not having Admn is not really such a big problem provided one condition is fulfilled. This condition is that whiever is the admin should giveimmediate service when asked for. It would be ridiculous if I have to wait more than a couple of hours to add a single entry into my enviroment variables. If this kind of quick service is provided it will really help with security because over  the years I have had to accept the fact thatmost programmers are quite lax about security of their machines.
XP is a good OS to workon as it gives a lotof security and one can even install using the Run As: option. I use this mode even at home.
Last but most important, one may develop in any environment but testing should never be done in an administrators account. It should always be remembered that most clients will never work on admin accounts and it is better to test in environments that they work on.

Brijesh Kartha
Friday, February 27, 2004

Rules are created for the slightly dumb and immoral. Developers that can't handle a root password or mess up their computers on a regular basis should be fired, not restricted by rules. The worst one can do is limit all developers, because some can't behave themselves. Smart developers will also leave organizations with strict rules, making the software development organization even more mediocre in the long run.

Jan Derk
Friday, February 27, 2004

We have a similarly locked down SOE environment at the bank I work for.

Our Teamleader has all the PCs formatted and installed by our own admin guy before the developers do anything.  We get administrator access etc. etc. etc.  We just need to keep the 'corporate wall paper' in case someone asks.

Hopefully your team leader will have a clue.

Koz
Friday, February 27, 2004

It's all about letting programmers spend their time programming--not worrying about system administration.

There are examples where locking a system down is good and examples where it's bad, but if a developer can't get work done because the system is too locked down, something is wrong.

But the developers should not have to worry about making sure that all of the latest patches (except the ones that don't work with the office printer) get installed, data gets backed up, and computers are protected from viruses, etc.

Deciding how to do this depends on having the development team work together with the IT staff.

Jason
Friday, February 27, 2004

I find having the ability to install any software I want on my computer is very stimulating even if the software I installed is unrelated to what I am working on. It keeps you fresh with what's out there and provides idea for things to do with your own software.

If you have to ask permission to install something, then you get lazy and simply don't install anything and then you end up with old dinosaur type applications and that's what you end up developing.

S
Friday, February 27, 2004

Ideally, a developer should have two local accounts on the box.

One is the regular, non-admin account that they use day to day.

The other has admin privs, and is used occasionally to do stuff like install software, or restart services or something.

Chris Tavares
Friday, February 27, 2004

> - you can't start or stop services

> Not too much of a problem.

Unless your product runs as a service ... like ours does :)

Chris has the right idea ... two accounts.

A separate domain for developers is a good idea that works well too  I worked at a tech firm a few years ago and we insisted on this  ... we kept getting viruses from other departments.

Canuck
Friday, February 27, 2004

A fella where I used to work was frustrated at having to call over the admin to do ever little thing that he (we) were locked out of.  So he installed a hardware keylogger on his keyboard cable and VOILA he (and practically everyone else in software development) suddenly stopped having to depend on the admins.  They didn't even notice the sudden drop in people calling them over ever day for rinky-dink admin stuff.  Of course this is a double downside for them, because the account we now had access to was not just a system Administrator, but a domain Administrator as well.  Good thing developers are such honest folk and would never do anything like read the execs email, or pull up the salary spreadsheet from HR. 

Ken Klose
Friday, February 27, 2004

And in a further effort to ensure conformity all machines will be ghosted every night.  Please keep copies of all important documents on paper and re-enter them in the morning.

Rob Walker
Saturday, February 28, 2004

I have lots of sympathy with our IT support staff.  Someone with Admin priveleges can install just about any damn piece of software he can get his hands on, and then IT support has to somehow get his machine working again if it breaks.

However, like most draconian measures locking down admin priveleges does not SOLVE the problem.  Now the power users must request IT support for every clever thing they try.  IT either has to say yes, or the power users have to stop being clever.  Neither is a good solution.

I do like the two log-on solution.  When I do get Admin priveleges, the first thing I try to do is give myself a non-priveleged account, so if I do anything stupid without knowing I have done so the OS will help me.

However, the two log-on solution also has large administration costs.  I think this is the best of all possible worlds, but somebody is still going to get stuck with administering all those accounts and passwords.

Our solution has been to have me sign a nice piece of paper saying my group will now get charged for every trouble call I make which is Admin related, and then they gave me an Admin account.  So far this has worked pretty well.

AllanL5
Saturday, February 28, 2004

If admin access is required to do the work (developing), or makes the people doing the work more efficient, then they should have it.

We ghost machines, spend tons of money on network storage and backup so that people can have pretty much all their files on a server or backed up to a server.  We do our "standard" setup and any patches, upgrades.

Anyone with admin access (and their supervisor) signs a piece of paper that says that if they mess up their machine, we "fix" it by restoring the image and then their latest backup.  Anything else they've installed is up to them to restore.

Lets developers do what they need to, keeps us support guys from having to find/fix any serious self-inflicted problems.

Ward
Sunday, February 29, 2004

If a development department has to live within the same network as the business network then give them their own sub domain, give them all the rights they want to their own set of machines and simple user access to the rest of the domain.

If the developers need hand holding over system issues like installing printers and the like then give them that support but on the whole let them play in their own swamp.

Simon Lucy
Sunday, February 29, 2004

I was gonna write a long essay about this, then realized it's really about one thing:

If you don't trust your employees, you shouldn't have hired them.

Philo

Philo
Monday, March 01, 2004

We have a productive network where every workstation is absolutely locked down and we have the development network for all the development stuff where everything is possible. Program transport from development network to productive network is only done by a special quality team. So far so good.

We have many architects located in the productive network. They work with Rational software products. This is of course "nasty developer stuff" and not permitted in the productive network. So all these guys have a notebook with the rational software and a dial in internet account so they can exchange their architecture models via their private web mail account.
This is a real cool and secure solution!

Architect
Monday, March 01, 2004

"Dial up"? "Really cool"? Is this 1994? ;-)

jc
Monday, March 01, 2004

Sounds more like 1984!

Two "separate" networks isn't uncommon, especially in companies that have heavy investments in R&D and intellectual property (pharamaceuticals and biotech come to mind.).

Thankfully where I currently work we have only one network. Unfortunately the official policy is that developers aren't given local admin access on their PCs. In my previous company I was a domain admin, so it was a big change to come here. As Philo says it's about trust, and I've pointed this out to management lots of times.

Though maybe they are right not to trust us, as most of the better developers end up taking local admin access anyway (Hint: "at" jobs started by administrator run as administrator even if the SAM file changes in the interim.).

MugsGame
Monday, March 01, 2004

When it comes to Windows development, I wouldn't even consider working at a place that won't give developers local-machine admin access.  Completely ridiculous...  I can't see how you wouldn't bump into walls nearly every single day in such an enviornment.

Doesn't apply as much on the UNIX side where you can generally get by as a developer without root access much more easily due to being able to install most apps into your home directory, lack of registry, etc. 

I think people on the IT/SysAdmin side do a useful job generally, but I've run into a handful that forget that their primary job is to enable other people to do their jobs.  Keeping all boxes totally locked down might make the admin's job easier, but if it makes everyone else's job significantly harder, they've failed in their true mission.  The worst, in my experience, tend to be those with primarily UNIX-based backgrounds (who also do some Windows-admining) who don't understand exactly how limiting a Windows box without local-admin can be because they've never had to deal with such a thing on a day-to-day basis.

Mr.Fancypants
Tuesday, March 02, 2004

*  Recent Topics

*  Fog Creek Home