Can Developers Work in a 'Locked-Down' Environment?

brad-d queries: "My company is seriously considering enforcing a SOE on all employee computers, including developers. The level of lock-down would likely include baring the Windows registry from changes (and in effect stopping the installation of new software). The goals of this SOE are to prevent users from installing unlicensed software, plus some support issues. What are others experiences with situations like this? Can a developer really work in a lock-down environment? What compromises could be made between developers and IT services? And no, Linux would be likely banned." It depends on how "locked-down" said environment is, and what the developer would be will be working on, however if the Registry is locked with no mechanism provided for the Developer to add in whatever keys are necessary, how much real developing can one do?

Comments

Registry lockdown?

[syates21]

If all areas of the registry are completely "locked down", I don't even think a lot of *existing* application would run, let alone installing new ones.

Re:Registry lockdown?

[Chuck Milam]

I don't even think a lot of *existing* application would run...

Yes, I've seen this before. In a university environment I used to work in, we tried to lock down the registry...we had to make so many exceptions for various application that required full registry access to run (scary), that by the end of the semester we gave up on locking down and went back to rebuilding the systems nightly (which introduced a whole group of other messes...)

Re:Registry lockdown?

[platos_beard]

If the powers that be lock the registry to prevent writing to HKEY_CURRENT_USER, of course they're going to break a ton of apps. It's there for storing user settings.

OTOH, locking down HKEY_LOCAL_MACHINE makes perfect sense and programmers who use it for user-settings should be shot. Twice.

Developers need to write the administrative portions, so they really can't be locked down. Giving a programmer a C compiler and no registry access is like giving a soldier an Uzi, but no ammo except rubber bands. Well almost.

Re:Registry lockdown?

[olsonde]

I'm assuming we are talking Windows NT/2000/XP?

I'm also assuming by "Lock-Down" you are saying they have no rights to use Registry editing tools (regedit, regedt32, reg, regdmp, etc.) Also, no file permissions have been changed from their default.

By default, only "Administrators" have the ability to add or change keys in "Classes_Root". All users have full control to their own user hive (ntuser.dat).

For "Local_Machine, only "Administrators" have change ability to "Hardware";and "Administrators" and Power Users" have the ability to change keys within "Software".

As a developer, all developed programs should be able to be used by a person with only local "User privileges", but the person installing the application will need to have administrative privileges, because they will need access to CLASSES_ROOT or LOCAL_MACHINE.

So, if I was a developer writing an installation program, I would need to be able to test my installation code on a machine where I had local "Administrator" rights, but I would not need to have those rights on a machine I was compiling my source code on, since that only needs file permissions.

Where I work, the developers are normal users on their development machines (Visual Studio, Team Fusion, etc.), but they test their applications on machines set aside specifically for their testing purposes (their development and test machine sit side-by-side, sharing a monitor, keyboard, and mouse through a KVM switch). The test machines get wiped out and re-imaged as much as a dozen times a day (with a bootable CD image), but their development machine is rarely touched by IT.

In the rare instances where an app or development tool must run as local admin, we use the SU tool of the Windows NT/2000 resource kit. SU (we call it the Super User tool) will allow a specific application to run with elevated privileges.

We also use a freeware tool called RegDACLS to change registry key security to allow evelated access to specific keys in the registry.

No, you can't.

[dmorin]

Easy question : no. My group has our own Unix boxes and our own support group for most things except DNS changes and stuff like that and we still run into inefficiencies in getting routine things done on time. We do not have administration rights for our NT desktops in the sense that we can bring in our own OS upgrades, but we do have the freedom to install new applications. I can't see it working any other way.

If whoever is thinking about making such a decision is in charge of development, then get your resume in order because if I were you I wouldn't want to work under him much longer.

Re:No, you can't.

[ladykadyj]

I would wholeheartedly agree with dmorin. I think it's perfectly valid to have a development department in charge of their own "space". I've worked in that environment very successfully and at the satisfaction of both the development and IT groups. They stayed out of our way and we actually helped them with some of their problems.

I've also worked in an environment where the implementation group controlled everything (this was just when SMS came out, I still have the shakes), your computer was set up for you, they periodically came around and uninstalled screen savers and whatnot... but imagine monday morning when you come in to work and your computer gets the BSOD because some nitwit from tech support messed up your registry when ensuring your computer was "compliant" with corporate policies, or they screwed up your file links and now gcc can't find your mysql header files because you had a "non-standard" installation... Occasionally they would allow us to make the necessary changes ourselves if we were buddies with the technician -- let's face it, I feel more comfortable in my abilities to maintain my computer, I use the thing every day for crying out loud!

I can understand the IT department's headaches from users who screw up their machines, but developers are typically smarter than the average Outlook user (hopefully??) and can manage their own computers just fine. Computers as company property and subject to coroporate/IT policies is one thing... coding with my wrist chained to the chair is another.

Freedom is not for the ignorant.

Trust?

[Nick]

If you can't really trust your developers, and need some restrictions in place like that, then maybe you shouldn't have them working there in the first place?

Re:Trust?

[scoove]

It is rather amusing, not trusting developers. By definition (apologies for being redundant), but developers do not work in a static environment.

Having been in both ends of the pool, it never fails to amaze me at all the rules the corporate "golds" make up, then act surprised when development objectives get missed.

I'd suggest a copy of Yourden's "Death March Projects" be left on the culprit gold's desk for their inspection. It won't work, but it'll be worth a few good stories.

*scoove*

They can't

[well_jung]

We faced this issue when standardizing/locking desktops during our upgrade to Win2000. The only workaround that was agreeable to both sides (developers and IT) was to allow developers to have free reign, but not to expect anything more than "We can re-image the machine" from IT when said developer screws up his machine.

If you get out a bible and swear to IT that you are willing to not ask for support when you screw shit up, they may be open to letting you be blessed.

Yes, but at a much slower rate...

[Gid1]

I'm just at the end of a six-month contract to put together a PHP/MySQL/Apache based website, in a locked-down Windows 95 (!) environment with a few thousand users.

They're migrating to W2K shortly, but I put my foot down and they allowed me to wipe my box and install RedHat on it -- the only way I managed that was the fact that it was in a nice shrinkwrap box.

Well, all fine, but I get no support and I'm not allowed to put it on the network, so it's sneakernet for me. Access to the internet is done with floppies. =(

The point is that you may be able to persuade them to let you have a purely standalone machine, as long as you keep an SOE machine next to it for running Outlook =)

Development Lab

[ThomasMis]

This is just an idea off the top of my head. But would your company be apposed to the idea of having a developers lab that would be off the corporate network. This lab would be sort of an anything goes environment, where developers could mess with things such as what ActiveX controls are installed, keys in the registry, and what component versions live on the box (anybody familiar with ".dll hell"?). If the developers screw something up, it's up to them to fix it. The IT support staff wouldn't have to be involved at all.

Where I used to work at we had something similar called the time warp lab, that had a bunch of machines running different versions of windows with different components installed. The developers could test their code on them, and when we were done, we just ghosted a new drive image onto the drive.

Re: What is SOE??

[antidigerati]

SOE = Standard Operating Environment

Just so ya know... I had to look it up ;)

antidigerati

Re:SOE?

[Gill Bates]

(guessing)
Standard Operating Environment or
Standard Office Environment

Not Enough Information

[pmc]

As the sort of person who designs these policies I have to say that there is not enough information to give you an answer, so if you don't mind I'll illustrate with a few principles that I work to.

Surprisingly enough, nobody implements such a policy because they are evil incarnate - you may not believe this, but it is true. The reason that policies are setup like this is purely to save money. And the money is saved because a huge proportion of support time is spent fixing PCs that users have wreaked because they've installed that cute new application.

This leads directly to the BOFH approach to policy - nail it down, and nail it down hard. Don't even let them log on without a letter from the Pope. This is a stage one policy. Support calls drop dramatically, user productivity is zero.

Now, a bit of reality is introduced. People have to use their machines, so against our better judgement we let them log on. And print. And even save things to the hard disk. This is stage two: most people can do what they have to do, support calls rise a little.

Then you deal with the exceptions. Depending on the type of user the general restrictions are lifted. There may be strings attached (such as the screw up and we'll only reimage) or maybe IT will arrange proper support for the application etc.

The point to remember (and so many people forget, especially people in IT) is IT support is not the business. If you are in the business of making widgets, or writing code, then IT support do not do this - they exist to help you do this. They exist solely to allow the business to function more effectively. They are "facilitators" (to use a horrible word). They provide a service.

If that service prevents the business doing things that are required for the business the the service is substandard and needs to be replaced. In this case that service is a policy, and it need to be replaced. I have designed a policy for devolopers, and the policy is

1. You get a standard PC with the standard loadset, and admin rights on the local box.

2. If you screwup we will only reimage.

3. If you repeated screwup we will still reimage, but we will start charging you.

4. All software to be purchased (if costware) and registered (registerware) via {specific person}.

Lockdown policies are loved bu IT departments, but if it stops you (or anyone) doing legitimate work then it is broken and needs fixing.

Let me answer from the opposing view...

[coupland]

Since I'm responsible for "corporate standards" for a big conglomerate, I'll try to answer from the perspective of "The Establishment".

Unfortunately many companies don't house full-time developers and instead prefer to outsource on a per-project basis. Because of this many of them are concerned only with making their app run, at the expense of others. ie - Develop an app that's dependent on IE 5.0 despite the fact many company sites only work under IE 4.0. Bad code all around, eh?

This leads many companies to implement lock-down and I have to sympathize. In a perfect world all your tools would be installed by your Desktop folk and even your development PC would be locked down. In a more realistic world you would have a more open development platform but all testing would be performed on a locked-down PC. A nice compromise since it affords you the freedom to install the tools you need (I think historically no Desktop support technician has ever installed Visual Basic 100% the way a developer wants it!) while still ensuring you are developing an app that doesn't stomp all over settings and files that other apps rely on.

Also, keep in mind that there is (essentially) no user context in Windows that "locks down" the entire registry. What it does is grant full access to user areas and no access to system areas. The only big difference here between "secure" *nix and "insecure" Windows is that in Windows full control is the default. There's no reason why lock-down has to be a bad thing for a developer. In fact it's often a good thing as it prevents the next developer in line from writing an app that will kill yours.

Hey, no problem...

[dasmegabyte]

I write in Java using a text editor and I haven't written to my registry in months.

In fact, when I first got here my system was locked down like a prisoner by accident (they thought I was an intern...god I hate being young) and I didn't notice for four months, and then only because I installed JDK 1.3.1 (which wanted to change my JavaPath).

Yes, Java CAN interface with the registry, but it's a heck of a lot easier to use object dumps and ini files (in xml of course). And since things don't need to be "registered" (more trouble than it's worth) due to the namespace and classpath, you end up with a very nice sandbox development environment.

I wish this effing COM object I've been trying to teach how to use the network all morning were written in java...

the described scenario is the exact one i work in

[circletimessquare]

the company will be unnamed, but it is multinational and deals with lots of $, so such a system is not merely an issue of overzealous, over-anal management, but one of government standards and important security. in said environment, development can be frustrating. here is how i adapted.

1. tiny apps. just like the recent post. since single executeables do not need to muck with the registry to run, you are able to utilize small powerful ftp clients, html editors, etc.

2. build your own box. i put my case to my manager's manager, and they made an exception for me. i had (until the sept 11 wtc disaster, in which my workstations were turned into crispy critters) 4 computers at my desk. two were standard company-wide locked-down builds, and the other 2 computers they let me install nt server from scratch. nt security just made sure they had admin rights on them in case the box did something not quite right. then of course, software support washed their hands of these boxes. i had to install my os and software, i had to maintain it. if i screwed something up on the box, it was all for me clean up. which was fine for me, i'm a developer, i can support my own box. i want to support my own box!

3. write stateless software. change your paradigm. become one with the great zen of concise programming for the wrong reason: not because you should, but because you have to. ;-) it is very frustrating to develop on a box you don't even have rights to the C: drive on (the case here). but, in a strange way, it makes you write code and think of apps in ways you didn't before. that is, stateless, no need to touch the registry at all. i know, this is impossible for some apps and i am talking theoretically here. but rather than store registry cookies to identify users and preferences, etc., why not identify who is using a computer by identifying who's logged via standard function calls, for example, and have all their preferences stored on some distant database? be creative. there is always another way than what seems to be the only way. wax on, wax off, danielsan ;-P

other tip: depend on nothing. my profile with it's personal settings blows up from time to time and is reset to the generic sucky settings and i have to personalize all of my standard apps all over again. after awhile, i made sure not to put too much faith in leaving my desktop and depending upon it to look the same the next day. batch job important standard settings to rejigger everything (drive mappings, odbc connections, etc.) in cases of nt alzheimer's.

finally, there's no getting around it, a locked down SOE sucks for developers. developer= power user. developer= someone who HAS to muck around with things regular users don't. so bring this up with management. you guys are special, obviously, the most thick-headed manager can see that. maybe, before they SOE everyone, you can convince them to firewall all you dangerous developers in your own domain and let you hack your installs to your hearts content, unsupported, insecure, untrusted, but necessary to build apps. ;-)

Locking down makes for useless development

[hyrdra]

A locked down system is as useful as a tool as a hammer is if it were barred from making marks in it's head.

Clearly, the process of developing suggests an errorenous progression; changes are made gradually. With the inability to make changes, one loses the ability to develop.

Most companies have a locked down test system, which serves as a scientific control, but having a locked down system for which to work and develop would yeild an environment where very litte work could get done. You need to be able to change a system to make something, its as simple as that. Imagine being requested to build a new house, or better the foundation of said house if the ground couldn't be touched.