Apache OpenOffice (AOO) Bugzilla – Issue 17779
security permissions issues with openoffice, if you want to run it as a user
Last modified: 2003-11-01 03:38:53 UTC
I couldn't find an openoffice catch-all section, as this applies to all openoffice applications. I listed this as priority one, which I normally would not do, because if OpenOffice is to be run by normal users on win32, it simply will not work without the sysadmin doing significant work to the installation, because of significant oversights in the development. OpenOffice/win32 will not work at all without significant permissions editing for a standard user. Amongst competent sysadmins it would be considered that standard users should not have anything more than read/execute permissions on the application directory. OpenOffice applications consistently ask the OS if they have write permissions over the executable running, and also I found to the following dirs, this is purely on startup: (I installed OO to D:\Apps\OpenOffice, this was using ooowriter.exe as the example, but the other app components require much the same privs) (It also wanted delete privs in some instances... in an app dir... nice) D:\Apps\OpenOffice\user\config\registry\instance\org\openoffice\Office D:\apps\OpenOffice\user\config\registry\instance\org\openoffice\Office\Common.xml.tmp D:\apps\OpenOffice\user\config\inethist.dat D:\apps\OpenOffice\program\soffice.exe D:\apps\OpenOffice\program\ooowriter.exe I excluded repeated requests for accesses on these dirs/files. It should be needless to say, but temp files should be in a temp directory. On win32 simply querying the user's temp variable setting would work fine. Also should be needless to say, an app should not be asking if it has write privs over its own executable :-)
This issue is actively discussed in the Users mailing list. My gut feeling is that it belongs to "installation", since it is true that it applies to all applications, but I will leave that to more learned minds to determine. Confirmed Tam
HI->TM: Not a wordprocessor problem.
TM->BH: I changed this one from "defect" to "enhancement" because this is not a defect. These are wishes for changes in our behaviour to install the whole application. Please have a look, thanks !
The directory tree you display shows that you did a single-user install on a multi-user operating system (e.g., Win2k or WinXP). The application is keeping histories, user dictionaries, user settings, etc, in the USER directory, as you can see. This directory would be, by default, in <BootDrive>:\Documents and Settings\<UserName>\Application Data\OpenOffice.org<version>\user\..., a directory the normal user has every right to modify. Similar problems come up when people do this on a *nix system, making a single-user install in root, then trying to run the application as a user. Your problem, then, would be resolved by doing a "network" or "multi-user" install, and be careful about changing the default directory when doing the "workstation" or "user" installation. Matt Needles OOo Trainer
The problem is caused by the user performing a single-user installation as administrator. It does not occur with a properly performed Multi-user installation. Unless further information shows that the reporter did in fact perform a two stage, multi-user installation, I would suggest closing this issue as INVALID, or reassigning it to Documentation (because perhaps the instructions aren't specific enough).
Alex -- I got the impression that his report was based on the desire to have the multi-user install either as the default installation, or availabe as an option at installation through the wizard, as opposed to determing the procedure through the installation instructions, which he did not read. In this particular case, improved documentation would not have solved the problem. I took the crux of his argument to be that the installation should be so easy, instructions aren't required. Tam
I wasn't aware of the command switch on the setup exe "-net" that would have set things up more appropriately for what I needed OO for. I'm closing this ticket in favour of setting up new enhancement tickets, though from what I'm reading on the users mailing list this might not be necessary.
.