Windows OSS Only For Administrators? 101
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?"
Re:OOo (Score:2, Informative)
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.
It's not just OSS (Score:4, Interesting)
Re:It's not just OSS (Score:5, Informative)
Re:It's not just OSS (Score:2)
I'd like to point out something. You can't always install software in linux without being an admin, unless you do --prefix=/home/you on most software, and if you get an RPM, then you need to be admin ( root ) to install those, or you need some admin rights.
Its not just windows, all OSes have th
Re:It's not just OSS (Score:2)
Re:It's not just OSS (Score:1)
They can, its just little used or known about. Simply right click the install file, "Run as..." and you can type your admin username and p/w and your away, it installs as if run by the administrator.
However, i must point out that i run my machine constantly in administator mode for the
Re:It's not just OSS (Score:2)
They can, its just little used or known about. Simply right click the install file, "Run as..." and you can type your admin username and p/w and your away, it installs as if run by the administrator.
I'm
Re:It's not just OSS (Score:1)
Re:It's not just OSS (Score:2)
Re:It's not just OSS (Score:1)
Re:It's not just OSS (Score:1)
Re:It's not just OSS (Score:2, Interesting)
In the case of firefox (Score:2)
Some plugins would be a useful thing for all users (such as perhaps a proxy chooser, which in XP I use for our laptop users), but others could be damn annoying if applied to everyone.
A "please enter the root password" (or select admin user/password for XP) for global-level plugins would work nicely... and a ~/.mozilla/firefox/userplugins for the non-global ones...
Re:It's not just OSS (Score:2)
Re:Not true (Score:2)
In our offices people use Windows, Mac, and (one)Linux workstations but everybody must save their files to the company file server, which has RAID drives, and backed up nightly to a remote location.
So if Bob the programmer with admin access FUBARs his workstation then we have to reinstall windows and some apps but the data is safe.
Seems like... (Score:2, Interesting)
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", thin
Re:Seems like... (Score:3, Insightful)
Further out on the extreme branch, one could either partition and install a few OS's, or use MS Virtual PC to create a few different "boxen" with different OS's, different patches, etc... to get a full view of what the project is(n't) compatible with.
Re:Seems like... (Score:1)
but what about them skinny developers? Dont they have any worth?
Re:Seems like... (Score:2)
Jupiter (Score:2)
Re:Seems like... (Score:2)
Install the program in My Documents (Score:1, Informative)
Are you surprised? (Score:2)
Both the developer and user cultures are shaped by this, and the result is software which can't properly be secured. I'm not surprised. Are you?
But FOSS apps? (Score:2)
Yes. Not for typical Windows apps, you're right, but things like OpenOffice and Firefox derive from unix projects and work fine in a reduced permissions environment on unix builds.
So why do they have trouble in reduced permissions environments for their Windows builds. Perhaps we blame the Windows porters for not being unix geeks, which goes back to your sugges
As a matter of interest... (Score:1)
On Linux this nag goes away if you simply say you're already registered. Is it different on winboxes?
Re:As a matter of interest... (Score:2)
It's unfortunate that the developers of OOo wrote the application this way. But, since it's open source, it should be quite easy to fix, and I anticipate a fix is probably right around the corner.
Re:As a matter of interest... (Score:2)
If you really feel the need to show it at runtime, then at least you should have the option to enter the info at install time - then it becomes an administrators problem if they didn't register/install OO correctly.
There's also a capabilities limitation involved. It'd be kinda neat if there was a way that an application (Id
Happens all the time (Score:4, Insightful)
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.
Re:Happens all the time (Score:1)
Re:Happens all the time (Score:4, Interesting)
Re:Happens all the time (Score:2)
Have you tried setting the security rights on those files specifically, such that "Everyone" is allowed to overwrite these files?
Backwards compatibility (Score:4, Insightful)
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 [microsoft.com] 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.
Installer & PocketPCs (Score:2)
The solution I used... (Score:5, Interesting)
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...
Re:The solution I used... (Score:3, Insightful)
You're absolutely right about it being an elegant solution. Ignore the naysayers and keep up the good work.
Re:The solution I used... (Score:2)
Microsoft should have used
c:\documents and settings\user\...\Application\
Of course, even unix is not perfect. The
It would be really nice to have
~/.etc/ - configuration (backup optional, no data loss if removed)
~/.var/ - data (this needs to be backed up)
~/.tmp/ - t
Re:The solution I used... (Score:2)
Few apps implement the spec, but hopefully that will change soon.
Re:The solution I used... (Score:2)
To John H, parent poster: Ignore the people that bitch about stuff being where it's supposed to be. Tell them to take it up with MS.
Re:The solution I used... (Score:1)
Re:The solution I used... (Score:2)
Anyway, I never check to see whether or not perl's $ENV{$HOME} or $ENV{$USER} variables were properly populated (my syntax may be slightly wrong, forgive me). If so, then $ENV{$HOME} = "c:/Documents\ and\ Settings/$ENV{$USER}";, and of course $ENV{USER} = userid.
I don't know if a similar convention exists in more
Re:The solution I used... (Score:2)
Openoffice (Score:5, Informative)
Re:Openoffice (and Firefox) (Score:2)
Many of the OSS apps I work with, work fine as long as you play by the rules (which is a huge part of security!). Can we mod an entire story as Troll?
Re:Openoffice (and Firefox) (Score:2)
There are three parts to security that many geeks (myself included, at first) do not typically comprehend.
Confidentiality - Can I control access to a resource
Integrity - Can I be sure that my resource has remained unharmed
Availability - Can I use my resource
In this case, not being able to install a plugin (as the original poster's and your example) is a loss of availability. If I'm to operate a normal user on my system, but I have to log out and back in as Administrator to install a simple p
Re:Openoffice (and Firefox) (Score:2)
Realise that a plugin is software. If you can't install the plugin that pulls the RSS feed then you also can install a bad plugin that strips email addresses out of webpages and sends those users spam.
If your installing and uninstalling software constanly then you ARE and admin (or doing admin work). You only want an admin to be able to install plugins as they affect every user on the machine.
That being said in windows if you wanted to install a plugin
Re:Openoffice (and Firefox) (Score:2)
Restricting users to preinstalled software does raise security. But users have traditionally had the ability to install and run software inside their home directories, and this is the default in XP, OS X, and UNIX. I'm not even sure it is possible in XP to keep execute permissions off homedirs.
Realise that a plugin is software. If you can't install the plugin that pulls the RSS feed then you also can install a bad plugin that strips email addresses
Re:Openoffice (and Firefox) (Score:2)
My solution is to make the account a member of "Power Users." Or make a special Power User account and "Run As" Firefox as that user.
Re:Openoffice (Score:2)
Change Permissions (Score:3, Insightful)
Re:OS X? (Score:1)
It's all about program design (Score:2, Informative)
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 searchp
Firefox Search Plugins (Score:2)
The same is true under Linux. On Linux, it is because search plugins are installed under the system-wide shared directory for firefox. I assume the same is true for windows. This is an inconvenient design! It often means that upgrades or reinstalls won't keep search plugins (you can remember to copy your search plugins directory first, of course). It also prevents user-secific search plugins. Does anyone know the r
Re:Firefox Search Plugins (Score:2)
Firefox under linux stores new plugins in ~/.mozilla/plugins
That would be under the users home directory. Each user can have different plugins.
You can also install them into a shared location for all users.
Ratboy
Mozilla Bug 232638 (Score:5, Informative)
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)
Re:Firefox Search Plugins (Score:2)
We had a plugin that put its temp files in sub folder of system32! We complained and the next version of the plugin install 95% of the plugin in the user profiles and the temp files also endded up in user profiles too.
It will take time but users must complain LOUDLY to the MFR for these chan
Re:Firefox Search Plugins (Score:2)
Your reason does apply to some programs. A custom piece of software littered c:\ (Not even %SYSTEMROOT% (or whatever the relative name for it is)), and c:\windows (even less excuse for that one!) with temp files.
The argument of requiring each user to have their own set of plugins & wating time/space is a poor one. Most modern OSs have user home directories & directories which can be use
OpenOffice on Multiuser Windows Systems (Score:2, Insightful)
Re:OpenOffice on Multiuser Windows Systems (Score:2)
-Logon as the Limited User
-Run REGmon and FILEmon using runas
-Launch OOO and do things
-meanwhile search in REGmon and FILEmon for "denied"
-Fix permission in Registry and File system
-Done!
-Publish the results to OO.org for others to follow and add on to it (just like GPL...)
This is teadious but not rocket science!
Re:OpenOffice on Multiuser Windows Systems (Score:1)
Re:OpenOffice on Multiuser Windows Systems (Score:2)
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.
Installing OO.o for Multiple Users [openoffice.org]. Worked on every Windows machine I've ever installed OO.o on, without fail.
That's why the OO.o F [openoffice.org]
Re:OpenOffice on Multiuser Windows Systems (Score:1)
Re:OpenOffice on Multiuser Windows Systems (Score:2)
Look, I'm not trying to knock OpenOffice, but the faq you pointed me to illustrates my point that there is a per-user setup that has to occur.
Perhaps I don't understand what problem you're encountering. As should be clear from the FAQ, installing OO.o for multiple non-admin users is quite simple:
Assuming an Admin ran "setup.exe /net" earlier, as a non-admin user...
Re:OpenOffice on Multiuser Windows Systems (Score:1)
Future Versions of Windows (Score:2, Interesting)
Re:Future Versions of Windows (Score:1)
Gave Up (Score:2)
Local administrator (Score:3, Interesting)
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.
KDE on Linux has the same problem (Score:2)
Re:KDE on Linux has the same problem (Score:1)
Re:KDE on Linux has the same problem (Score:2)
> do with running with administrator privelages verses non-admin privelages?
When a Windows application fails to run without Administrator privileges, it is usually because it wants to write someplace where it should not. For instance, many applications open their registry key requesting full access at all times regardless of whether anything is actually being written, even under HKEY_LOCAL_MACHINE. You can see the analogy clearly if you think of HKE
Re:KDE on Linux has the same problem (Score:1)
Re:KDE on Linux has the same problem (Score:2)
No, you were replying to my post, and I only have my home directory with 510 permissions, not on a read-only fs. Of course, I don't think that having no user-writable file space should prevent KDE from starting. If I just want to run Konqueror to look at some web pages, why would I need to write anything? It's just plain bad design; that's what I think.
Re:KDE on Linux has the same problem (Score:2)
If you can't write to your home directory, how can you write to ~/.kde/ to save the DCOP state anyway?
Re:KDE on Linux has the same problem (Score:2)
> you write to ~/.kde/ to save the DCOP state anyway?
My home directory is set with permissions 510 to prevent creation of unnecessary configuration files. It's not on a read-only filesystem.
> I'd hardly call being able to write to your own
> home directory "excessive permission"
I would when the application does not need to write anything. Unless I customize its settings in some way, there is no reason for it to write a configuration file at a
Re:KDE on Linux has the same problem (Score:2)
Except many apps consider "saveable settings" to include things not in their "Preferences" dialog - things like window states (position, size), open files, recent-files, etc. While a nice fallback of a "BTW these functions won't work" warning would be
Not too bad a problem (Score:1)
I have found some software that does not work properly but usually I have found something to replace them.
I have no problem with OpenOffice. I do not remember if I ran the setup while logged in as root or did I just right-click->RunAs it. Anyway, the limited user setup has to be done with a special -net switch. Read the installation docs.
I used