Slashdot Mirror
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?
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...)
SOE = Standard Operating Environment
;)
Just so ya know... I had to look it up
antidigerati
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.