To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=93447
------- Additional comments from [EMAIL PROTECTED] Wed Nov 26 14:53:45 +0000 2008 ------- GENERAL CONSIDERATIONS As you imply, 'inix paths are often problematic. In addition, usability must always be a paramount consideration. But to some extent it does not matter how integration is accomplished, the current approach still poses what may be serious security risks -- even for the average user. The OS should never be modified by any application -- even a "good" application like OpenOffice. INSTALLATION SCRIPTS Well-tested examples of installation shell scripts modifying paths might be found re both application and browser plugin, for both Adobe Acrobat and Mozilla Firefox. The Mozilla script is probably GPL'd permitting OpenOffice reuse. Another example is the Frame (now Adobe) FrameMaker installation script from as far back as the early 1990's. This is copyrighted, but could be used for its approach. The FrameMaker installation script pauses and requests specific permission prior to any system or user changes, and then is explicit about those changes. PTC Pro/ENGINEER also has a well-tested, multi-OS installation script. Please advise if examples would be helpful. Copyrights apply for both. If the OpenOffice installation script _must_ be run as root (a related issue), it should still explicitly request permission before modifying the user's path or anything else other than the application itself, including previous OpenOffice installations. PATHS If user paths are modified, it is common but poor practice to prepend a specific application's path before OS or display paths. This is functionally risky, un-secure, and philosophically selfish. For system-wide paths it is computationally deficient and may represent a near abrogation of security. There still is the option of appending the path system-wide and/or in the user's home directory. See the default files in Solaris /etc/skel for examples of csh and sh-family default paths (they use different approaches and both are needed for universality). These files may or may not be installed for specific users and if so are normally installed only for new users. If paths are modified, the old path should be commented out by placing "#" at the beginning of the line and the new version dated and commented by an additional # line. Files may not run without a minimal path: "./file.sh", if "." (access and run from the current directory) has not been placed in the system or user's path for security reasons. This is a minor but standard step towards keeping intruders from running corrupted versions of commands before the system version, not an issue of OpenOffice per say. Virtualization and containers makes this all more complicated still. COMMAND LINE INTEGRATION >From another perspective, it is unclear how often ordinary users actually use the command line. Current installation provides for menu integration for both CDE and Gnome, including a top-level icon to the left of the CDE main menu strip. This addresses opening up OpenOffice for general purposes or creating new files. The /etc/dt/appconfig/types/C/... files mentioned previously takes care of clicking on an existing file, at least in the CDE file manager. Power users should be able to either run a URL link (a text file with the full path to the as-installed binary) or run ~/.openoffice.org2/Scripts/openoffice.sh, with the actual installed path created once the user runs OpenOffice for the first time. RELATED INSTALLATION ISSUES As described originally, OpenOffice installation and operation as an application user:group (office:office?) rather than root:root is a related issue. It provides explicit user access/denial on multi-user systems by requiring that users be made members of the office group. In other words, this is not a path issue so much as access to files in the path. In addition, OpenOffice binary default location, path names, and a generic link to any specific release are all related and relevant issues. Sorry for my brevity, but there is much to address. It seems to me that you may already be well aware of most of the above and are simply and reasonably asking me to justify the issue. Most of the considerations discussed above are relatively simple to implement and would be expected to significantly increase OpenOffice related security and thus maturity as an other-than single-user application. Enterprise and government markets represent huge potential for world-wide OpenOffice adoption, but such deployments require greater consideration of these multi-user security considerations. Thanks. --------------------------------------------------------------------- Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
