Slashdot Mirror
Windows OSS Only For Administrators?
Torsten writes "We all know it: it is no good idea to run Windows with Adminstrator privileges all the time. But when you use a normal user account, many programs will not work properly. I have recently recognised that even open source software has difficulties with the Windows rights model. Openoffice will continue to ask for registration until an Administrator stops it. Firefox will not install new search plugins for normal users and will not even tell why. FlightGear starts the configuration screen, but only an Administrator can fly.
Have the OpenSource developers problems adapting the windows right model? Or does nobody bother being Administrator?"
It's not just OSS; Microsoft's own stuff doesn't necessarily work properly with restricted rights. The printer spooler on one of my home computers refuses to work, and in order to let my kids print anything, I had to turn off the spooler (which essentially hangs the computer until the printing is done). I have similar problems with peons and non-OSS third-party software, such as HP's software update tool.
Classical chicken-egg problem.
Since the majority of developers and testers develop/test with Administrators rights, these bugs slip through completely unnoticed.
How to change that? I don't really know.
And anyway there gonna exist many legacy (9x era) apps. These gonna require Administrators rights. Maybe "Run As" is going to help. But it's annoying to use: doesn't really remember credentials, doesn't have "remember admin password for XX minutes", etc.
Maybe if Microsoft implemented comfortable "Run As", things gonna change. Not now.
- Arwen, I'm your father, Agent Smith.
- Well, you're just Smith, but my father is Aerosmith!
There were a few issues with my software that needed me to consider multi-user access under Windows, especially as I was adding new features; when these features finally came to fruition, I modified my software, sticking preferences, application and temporary data either under the user's "Application Data" folder in "Documents and Settings" in Windows, or in a dotted directory under *nix. I thought this was an elegant solution.
So what happened? People yelled at me. Why was I polluting their system, putting files all over the place? Why couldn't I have kept it the way it was?
You just can't win...
Wasn't Microsoft planning to fix this problem in future versions of Windows by using virtual copies of the registry, so that each program could see its own copy of HKEY_LOCAL_MACHINE and do whatever it wanted to to the key because its copy wouldn't be the "real" master copy?
Textbook CD's are horrible. I'm the admin at a small college, and we run win2k in our student labs. Even the brand new editions of textbooks use Macromedia Authorware crap (really old versions, and some new) that will not run until they copy 2 files into %system32%. Of course, thats a big no-no to let student users have rights to this. If I manually copy the files into the directory, it still doesn't work, the program doesn't look to see if their already there. Even non-authorware stuff doesn't work right. I have a CD out of the back of a textbook that (from the CD) starts a java-based web server on some port, and then uses IE to connect to the web server. Of course, it can't write those registry keys, and it wants me to turn off all security in IE to run. It uses Active-X, so no go with firefox. .. I could understand this crap on an older textbook, but of few of these came out just this term, and they still expect everyone to be running Win98. If you call up the publisher, their solution is always to add users to the administrators group. .. idiots..
What are we going to do tonight Brain?
When setting up the new Active Directory domain here, I decided that I would rather avoid these problems all together by giving users administrative rights to their own workstations.
You can accomplish this by adding the user's domain account to the local Administrators group on the workstation. You set this on the system itself, not at the domain level. Doing so does not give the end users administrative rights to any other system -- just their workstation. No domain-wide administrative rights what-so-ever.
I felt doing this gave users the flexibility they needed to do their jobs, but was restrictive enough to keep users out of each others' systems, which was a concern of mine.