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!
If you spend enough time with NT-derived versions of Windows, you'll find that a lot of software simply assume that it is running under Windows 95/98/ME or require that you do some fiddling with permissions on the filesystem or registry to run properly. This causes me no end of grief as I try to keep our PCs sufficiently protected from stupidity while being functional enough to avoid receiving support calls.
All of the examples given can be duplicated in commercial software. MS Office 2000 won't stop displaying the "please register" nag dialogue box until an admin dismisses it. Regular users can't install plugins in Internet Explorer either, although I guess one could set the plugins directory to Everyone:F, but that's big security hole. One little commercial programme we use here to track fixed assets won't run under a regular user account unless its registry key in HKEY_LOCAL_MACHINE is set to full access to everyone because it keeps running state information there. Nero Burning ROM will not burn dics under a regular account without installing an extra utility that grants disc burning privileges to admin-specified users or groups. Palm Desktop, even in its current iteration, keeps user data in its programme directory, which requires the admin to set the directory's permissions to Everyone:F - again, another gaping hole. The list goes on and on, and it goes to show that a good part of the crappy Windows user experience is caused by the lousy software that runs on it.
In Soviet Russia, Jesus asks: "What Would You Do?"
Windows 9x apps could drop files anywhere they pleased, and they did: the Windows directories, app directories, the root of the drive, you name it. Windows NT/2K/XP solved this issue with the "Documents and Settings" area, and that's supposed to be where apps put their temp files, logs, databases, and other data. But most 2000 and XP systems loosen security to make old apps work. (How could apps write .INI files in the Windows directory otherwise?)
Since old apps don't break, developers are tempted to follow bad examples or old habits. It seems like the only way this would change is if Microsoft shipped XP as secure by default--the default user would not be an admin, and NTFS security was set to prevent writes to Program and Windows dirs. That would cause a massive support headache.
The Windows Installer docs have some guidelines on where things should go for best compatiblity, but of course a lot of people use other installers and those may not try to enforce any rules. This doesn't seem to be an issue that Microsoft is crusading about, but maybe they should.
They don't spam, that's for sure.
I use a unique address for every e-mail address I give out, and the one I gave openoffice has not been one of my spammed entries.
On Arrakis: early worm gets the bird. Magister mundi sum!
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...
If you had read the documentation, you would know that in order for Openoffice to run as a normal user and save your settings, you have to run the install as "setup.exe -net" -- just like you have to do in Unix.
If you trust the software, just grant the Users group extra permissions & file a bug report for what you had to do. In environments where I trust the users, I am lazy & grant users the same permission for the apparently relevant files and directories as the accounts that can run the software. On some occasions, this includes changing permissions of dlls outside of the installation directory. I use listdlls to do this. In less trusted environments, I will gradually add read+execute access for the users to the programs & dlls users need. If I get sick of trying to fix it, I usually reevaluate the need to install the program or the level of trust to grant the users.
In my experience, this is just a program design issue. I'm using linux, and I've never had any problem with it. Allmost every program in linux doesn't need root priveliges anyway. And the ones who do (like XCdroast) provide a special interface for it. Still not satisfied? Use su or sudo to run it temporairly in as root.
However, I had this one problem with firefox search plugins. The reason why most users can't update the searchplugins is because the dir containing the searchplugins is global, and a standard installation doesn't allow uses to write in it. This is rather unacceptable behaviour in Linux. Bugs like that just prove how some developers are unaware of multiple users and priveleges.
In Windows, the situation is rather different. Most users don't need multiple accounts on one desktop. So it's not a big problem (they think), because they are in charge anyway. This way, a lot of programs running on Windows don't bother providing a multi-user interface, but just stick to a global configuration. With this attitude, it's just asking for problems
- Never underestimate the power of human stupidity.
I'm not trying to through rocks, but trying to highlight a need... Running OpenOffice on a Windows system with multiple users where said users are not administrators is a problem for me and an impediment to the adoption of OpenOffice for many of my clients. Most Windows software I run needs to be installed only once while administrator and then all other nonpriveleged users can run the software. This doesn't appear to be the case with OO. I don't get the per-user install requirement for OO. This problem is most pronounced on Citrix. I found an ugly script that includes multiple reghacks on OOOforum.org that I will soon test, but in general, this issue has got to be an impediment to OO deployment on many Windows networks.
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?
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.
Search plugins, which the story refers to on win32 & which I refer to in my response, are installed to the installation folder. On the box I'm currently on, that is:you have to install as root with the default permissions.
This is a known bug: look at bug #232638: (no linky because they don't allow links from slashdot)