Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Windows Operating Systems Software

Windows OSS Only For Administrators? 101

Posted by timothy from the hey-buddy-you-gotta-be-an-admin dept.
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?"
This discussion has been archived. No new comments can be posted.

Windows OSS Only For Administrators? More

Windows OSS Only For Administrators?

Comments Filter:

  • It's not just OSS (Score:4, Interesting)

    by yelvington ( 8169 ) on Wednesday January 05, 2005 @01:27PM (#11264788) Homepage
    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.

    • Re:It's not just OSS (Score:5, Informative)

      by Apreche ( 239272 ) on Wednesday January 05, 2005 @01:34PM (#11264853) Homepage Journal
      It's not just windows either. I always have problems trying to add extensions and search plugins to firefox as a non root user in Linux, and it hardly ever works properly. The problem is that applications are written in such a way that in order for the ordinary user to accomplish a simple task deep underneath there is a small operation like a file system write that must happen. As is in the case of installing an extension. What needs to happen is the application developers need to make sure that for any action which should be allowed for a non root/administrator user that there are no priveledged instructions to be executed.
      • ditto here. I've had problems on both OS and the BSD's when not admin. Some Firefox extensions install in user profile, others are global. The global ones are the ones that cause problems, probably for both OS.

        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

        • There is a difference between installing software and using it. Using the software should not require admin/root privliges while installation can. The way I have seen linux boxes usually set up is they work along in user mode and when someone needs new software they either switch to root to install it or get an admin to do it. Windows should be able to do the same.
          • "The way I have seen linux boxes usually set up is they work along in user mode and when someone needs new software they either switch to root to install it or get an admin to do it. Windows should be able to do the same. "

            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

            • Using the software should not require admin/root privliges while installation can. The way I have seen linux boxes usually set up is they work along in user mode and when someone needs new software they either switch to root to install it or get an admin to do it. Windows should be able to do the same.

              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

        • A bit OT, but your post has reminded me of something I've always wondered about. Has someone come up with a "User" level version of APT or YUM? i.e. something that allows a non-root user to install packages in their own little userspace corner of the filesystem?
        • If you want to give users the ability to install extensions into the firefox directory, you can just chmod it. Ditto for any directories you may want to allow users to install into. If you want to install stuff using your user account, but don't want to set permissions, use sudo. In Windows, you have cacls. The methods exist for you to allow users to install software, but they all require some setup, as they should. An OS that allows users to install things to any directory they choose out of the box wouldn
      • I can't agree with that... Linux is kernel, what you are reffering to is distribution (like Fedora or Debian) - so in Linux (meaning distro) software is installed completely different than in Windows - in Windows you get installers from all over the Web and push them to system (they usualy work). In Linux you download packages with given software (here Firefox) from less or more official repository of software *customized* *for* *your* *Linux* *flavour (aka distribution). So the proper way of installing Fir
      • Sorry, folks... it's really simple. If you're installing software packages or widgets that plug into them, you're performing an administrative task. That's why they call them administrative rights, dolts. Neither well-configured Windows (well, 2k, XP or 2k3/SBS anyway) nor Linux nor BSD (free, OSX, etc.) nor proprietary UNIX (Solaris, HP/UX, etc.) in my experience deviate from this simple notion. And if you have half a tendency towards laziness, you find simple ways to automate any context-shift you may nee
      • Maybe what we need are user-level and administrator level plugins?

        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...
    • My parents have some model of Canon MultiPASS printer that was released during the Win9x days. They're now using WindowsXP and the Canon-supplied XP drivers for the printer. These drivers don't work unless you're logged in as an administrator. The "drivers" involve a little tray icon that shows the printer status and lets you do other crap, but if you try to print when you're not an administrator it is like Windows doesn't have the privileges to connect to the MultiPASS daemon or something. I've not found a

  • Seems like... (Score:2, Interesting)

    by sw155kn1f3 ( 600118 )
    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", thin

    • Re:Seems like... (Score:3, Insightful)

      by I8TheWorm ( 645702 )
      Create a test account on the box with very few privileges. Really, any developer worth their weight ought to know to have a non-development environment to test projects.

      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.

  • Install the program in My Documents (Score:1, Informative)

    by Anonymous Coward
    On my home machine I am the only user. For day to day things I run as a limited user. But I want to run programs like eMule (only to download legal things, of course). But eMule is constanly writing to its temp folder. So I just installed eMule under the My Documents folder as a limited user instead of Program Files as Administrator. You have to run eMule once as Administrator so it can write something to the registry but after that you run it as limited user.
  • Windows NT may have proper separation of users, but most people and most software came to Windows through DOS and Windows 9x, which are single-user.

    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?
    • 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?

      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
      • The submitter of the thread says that "Openoffice will continue to ask for registration until an Administrator stops it".

        On Linux this nag goes away if you simply say you're already registered. Is it different on winboxes?

        • No, because OOo is trying to write the results of that question (no matter which way you answer) to an area of the filesystem/registry which is locked down to administrators only.

          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.
          • What the solution here should be is that it shouldn't display the nag screen at run time at all - it should be done at installation time only, when admin rights are legitimately needed.

            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)

    by red_dragon ( 1761 ) on Wednesday January 05, 2005 @01:51PM (#11265018) Homepage

    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.

    • Yes but wait. (I am reffering to your 1st paragraph). I understand that 9x was different and now we have XP. OK but this is like something that is easly predictible is it? Like when you design modern multiuser system, where users are separated for system and you know that older legacy programs will have trouble with that (due to different permissions) than you can perdict and manage this also. I don't know Windows much but XP has something like compatibility mode where you run 9x programs in somekind of emu

    • Re:Happens all the time (Score:4, Interesting)

      by QuantumRiff ( 120817 ) on Wednesday January 05, 2005 @05:06PM (#11268284)
      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..
      • 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.

        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)

    by kawika ( 87069 ) on Wednesday January 05, 2005 @01:53PM (#11265043)
    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 [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.

    • I have a PDA running the PocketPC OS. It is very nicely integrated into a host Windows system which I have retained. However due to the wonderful Windows Installer, PocketPC software must be installed via Administrator on the host PC. WTF????? There is no admin on the PocketPC OS and I can manually install stuff without problems.

  • The solution I used... (Score:5, Interesting)

    by TheSHAD0W ( 258774 ) on Wednesday January 05, 2005 @02:18PM (#11265418) Homepage
    There were a few issues with my software [bittornado.com] 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...

    • Re:The solution I used... (Score:3, Insightful)

      by Anonymous Coward
      Thanks for the great BT client, works great out of the box, no tweaking necessary and it complies with the windows idea of where app settings and the like should be stored.

      You're absolutely right about it being an elegant solution. Ignore the naysayers and keep up the good work.
    • Personally I find the depth in which "Application Data" is placed too hard to find.

      Microsoft should have used /home/user/Documents is much better than

      c:\documents and settings\user\...\Application\

      Of course, even unix is not perfect. The .dotfiles are starting to be a big mess. It's hard to decide what is junk there and what is actually worth backing up.

      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
      • You might want to look at the Freedesktop Base Directory Spec [freedesktop.org]. It defines the use of $XDG_CONFIG_HOME (default: ~/.config/) and $XDG_CACHE_HOME (default: ~/.cache/) as a root for applications to store their configuration data and temporary cached data, respectively. I would think that the app itself should ask you where you want to save data files and whatnot.

        Few apps implement the spec, but hopefully that will change soon.
      • Incidently you can change this when you install Windows. Use a response file (google Microsoft's KB for winnt.sif) and specify the location and name of the profiles directory. Mine is "C:\Users". Also, you can install Windows into any directory you want using this technique.

        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.
    • Well you could give an option - where to store the configs. :) My friends from highschool are doing IM client from some time. It is actually good and upon first run it asks where to store user profile ("Program Files" or "Application Data" in user profile dir). They made it so maybe because of backward compatibility with Win9x - I don't really know - I don't use Windows (other than administering few XP boxen) since three years... Maybe that is it? If they complained about storing configs in $HOME on *nix -

  • Openoffice (Score:5, Informative)

    by Anonymous Coward on Wednesday January 05, 2005 @02:28PM (#11265578)
    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.
    • Firefox not installing plugins by default using an unprivileged thing is a GOOD THING. I think the poster of this article needs to step back and look at the security model and why it exists, not only that it exists.

      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?
      • I disagree.

        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

        • You don't want users to be able to install software.

          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
          • You don't want users to be able to install software.

            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

        • That said, firefox is an exception in my book, but my solution is to run as Administrator, which is not a good solution either.

          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.

    • Ah, I'm glad someone else on this forum knows this. It's worth noting that this irritating limitation is gone in OpenOffice.org 2.0--there is no longer a need to maintain a machine-wide "network" install, and separate user installs for each user.

  • Change Permissions (Score:3, Insightful)

    by Noksagt ( 69097 ) on Wednesday January 05, 2005 @02:45PM (#11265935) Homepage
    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 [sysinternals.com] 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.
  • But when you use a normal user account, many programs will not work properly.

    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 will not install new search plugins for normal users and will not even tell why.

    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

    • WTF?!?

      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)

        by Noksagt ( 69097 ) on Wednesday January 05, 2005 @05:59PM (#11269122) Homepage
        You are absolutely wrong. The location of search plugins and extensions is distribution-secific. On my distro you can install extensions to:
        ~/.mozilla/firefox/default.{profile}/extensions
        which means individual users can install their own extensions (which I believe is what you refer to).

        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:
        /usr/lib/MozillaFirefox/searchplugins
        you have to install as root with the default permissions.

        This is a known bug: look at bug #232638:
        https://bugzilla.mozilla.org/show_bug.cgi?id=23263 8
        (no linky because they don't allow links from slashdot)
    • The reason why is that otherwise every user would need to have their plugins installed on a per-user basis. Each new user would need to have all their pluging installed. Drive space is wasted too for duplicate files.

      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
      • Thank you for your post. Please see my previous post [slashdot.org] which I made after research this secific grie a bit more.

        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
  • 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
    • -Get REGmon and FILEmon.
      -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!

    • 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]

      • Appreciate the response. 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. When we are talking dozens of users on a Citrix farm of multiple servers, it gets pretty tedious. Forget Citrix for a minute, how about an evironment where one might work from different machnines. I found some articles in the forum about others that have set it up such that the per-user setup is scripted and silent that I will try. My or

        • 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...

          1. Navigate to the install directory (likely Program Files\OpenOffice.org)
          2. Click on soffice.exe
          3. Watch as OO.o runs user-specific installation
        • I really appreciate the time and detail of your post. It actually has been a while (v1.0) since I have tried to install OpenOffice on Citrix. I am going to suspend further comment until I spend some time first hand on this issue (after reading the FAQ ;) ) Thanks again.
  • 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?
  • My Ma and Pa are administrators, that i hate, OO.o installed in my account, didn't have the file associations transported to my mum and dads, wierdness...

  • Local administrator (Score:3, Interesting)

    by Matty_ ( 74368 ) on Wednesday January 05, 2005 @05:12PM (#11268386)
    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.
  • Do you know how to get KDE to run with a read-only home directory? You won't find the answer in the documentation. Searching the net yields helpful advice to set KDE_HOME_READONLY=true, but it still doesn't work because DCOP wants to write its state file in the home directory (now, who came up with that idea?). Naturally, there is no help anywhere to be found. But, if you happen to be a programmer and have time to comb through hundreds of lines of code, you can figure out that you also need to set three add
    • What does locking down your home directory have to do with running with administrator privelages verses non-admin privelages? Most people use KDE in non-root mode most of the time, and occasionally enter a root password to do system-wide stuff.
      • > What does locking down your home directory have to
        > 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
        • Agreed, but I was replying to someone who was trying to make their whole home directory read-only and then run KDE. This is different than what the original thread is about.
          • > I was replying to someone who was trying to make their whole home directory read-only

            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.
    • I'd hardly call being able to write to your own home directory "excessive permission"...

      If you can't write to your home directory, how can you write to ~/.kde/ to save the DCOP state anyway?
      • > If you can't write to your home directory, how can
        > 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
        • 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 all, and it most certainly should not refuse to run if it can not create one, like KDE does.

          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
  • I am running Windows XP Pro and each member of my family has a limited user account. Additionally there is one account named "root" that has admin priviledges.

    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

Slashdot Top Deals

Understanding is always the understanding of a smaller problem in relation to a bigger problem. -- P.D. Ouspensky

Close