On Mon, Apr 27, 2009 at 10:03 AM, Asiri Rathnayake < [email protected]> wrote:
> Hi Devs, > > Jodconverter 3.0-beta-2 version has been released: > > http://groups.google.com/group/jodconverter/browse_thread/thread/8b73b26b701c3249 > > One of the most important fix for us is the first point mentioned there: > > "OOo is now started with -nofirststartwizard by default. This avoids the > frequent problem of OOo refusing to work on a new machine because it's > expecting somebody to accept its license dialogue even in -headless mode" > > Without this fix currently we have to copy an already initialized ooprofile > directory to the destination server and point to it from xwiki.properties > file. This is a pain. +1, However, I'd also like to express a wish for the ability to launch the openoffice server the "old fashioned tedious way" for those with security concerns and a desire for standards of service administration on web servers. Does this new release re-enable that capability that was removed from 1.8M2? IMHO, many security-conscious administrators will prefer to have control over this service via traditional and accepted mechanisms like chkconfig(8) and /etc/init.d/ scripts. They may be surprised or made uncomfortable by the notion of an externally accessible Internet application running in a java web server that launches a rather extensive "untrusted system" (openoffice running as a server) and runs it with the same exact privileges as your "trusted" web server and "trusted' java and Servlet spec, thereby potentially "tainting" all, as well as exposing unexpected privilege-escalation exploits <http://en.wikipedia.org/wiki/Privilege_escalation>. >From a security standpoint, it would be nice to have "separation of concerns<http://en.wikipedia.org/wiki/Separation_of_concerns>" and "separation of privilege<http://en.wikipedia.org/wiki/Privilege_separation>" : run the Openoffice server as a different "user" on the system that can only write its own home directory and /tmp but not have the same access capabilities given to the java web server (and vice-versa). The 1.8M1/M2 releases where this advice still applied, required that both OpenOffice server and the java web server be run as the same user (tomcat). This does not have to be a fundamental limitation of the "named pipe" and unix-domain ipc used -- it's a limitation of the OpenOffice server or its configuration. Below is a section I wrote for http://code.xwiki.org/xwiki/bin/view/Applications/OfficeImporterApplicationto deal with this issue. > Installation notes for Fedora 10 > > Strange bugs can occur if the incorrect or incomplete openoffice install is > selected, or if this particular build of openoffice is run with a different > Java JVM than the GNU GCJ which "yum" loads as a dependency of OpenOffice. > After numerous troubles with the OpenOffice server using the default Sun JDK > used to run Tomcat and Xwiki, I set the JVM used by OpenOffice back to "GCJ" > and things began working reliably and quickly. Therefore these instructions > assume you've done "yum groupinstall 'Office/Productivity'" and "yum install > openoffice.org-headless" and have the entailed Java dependencies installed: > 'java-1.5.0-gcj' , 'sinjdoc', 'java_cup', 'lucene', 'saxon', 'jdom', > 'xalan-j2', … See > here<http://jira.xwiki.org/jira/browse/XAOFFICE-5?focusedCommentId=35043&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_35043>for > details. > > The OpenOffice server currently must run as same user running the Java Web > Container. For example, if user 'tomcat' runs the Tomcat server, then the > same user must be used to start the OpenOffice server. However since > 'tomcat' is not a login account, the OpenOffice server setup requires a > first interactive run of the application via the "console" or remote X > server. This allows it to write configuration files used when it is launched > as a server. > > First, we create a new account 'OOo' to run the Open Office server > interactively for its first run: > > ROOT-MYHOST-105-~> useradd --user-group --password MYPASSWORD OOo > ROOT-MYHOST-106-~> cp -rp .ssh ~OOo ## optional copy existing user's > SSH credentials, for remote login > > ROOT-MYHOST-107-~> chown -R OOo ~OOo/.ssh ## optional change ownership so > SSH works > > Log in to this account "OOo/MYPASSWORD" via console or via "ssh -Y > o...@myhost". Run OpenOffice launch program 'ooffice' once either from the > SSH session or from a console menu or terminal. From the menu-bar, select > "Tools->Options..." and from the "Options" dialog, open the "Openoffice.org" > hierarchy and select "Java." In "Java options" be sure "Use a java runtime > environment" checkbox is selected, and that the "Free Software Foundation > 1.5.0" (/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre) java is selected. Then > click Ok to submit the "Options" dialog. Finally, select "File->Exit" from > menu-bar and openoffice should save this configuration for future use by the > OpenOffice server. > > Now that OpenOffice is setup for interactive use, we now need to change it > over to a "server" setup. This is done by changing permissions on the ~OOo > home-directory so that 'tomcat' can write the directory. Since we're no > longer going to login on the "OOo" account, first thing we do is disable it: > > > chsh -s /sbin/nologin OOo ## you may also want to !! away the > associated password in /etc/shadow > > Openoffice uses two directories to persist "user" files in ~OOo; > 'ooserver-start' also writes log files into ~OOo. Therefore we set > permissions for the affected directories: > > ROOT-MYHOST-112-~> chown -R tomcat.tomcat ~OOo/.openoffice.org > ROOT-MYHOST-113-~> chown -R tomcat.tomcat ~OOo/.fontconfig > ROOT-MYHOST-125-~> chown tomcat.tomcat ~OOo > > The server invocation is: > > sudo -u tomcat /usr/local/bin/ooserver-start > > Sudo <http://fedorasolved.org/post-install-solutions/sudo> is used to run > the script /usr/local/bin/ooserver-start as user 'tomcat': > > #!/bin/bash > export OO_SERVER="/usr/bin/ooffice" > export OO_FLAGS="-nofirststartwizard" > export OO_ACCEPT="socket,host=127.0.0.1,port=8100;urp;" > > export OO_LOG="OOSERV.log" > export USER="OOo" > export LOGNAME="$USER" > export HOME="/home/$USER" > > unset DISPLAY #### Prevent OO from running interactive; > force failure on missing openoffice.org-headless > echo DISPLAY="$DISPLAY" #### for details, see > http://www.artofsolving.com/node/12 > > echo Cleaning up in $HOME > cd $HOME > killall soffice.bin > killall soffice.bin ### second kill's error message means the > first one succeeded > rm -f .openoffice.org/3/.lock ### Lockfile left from previous ^C'd invocation > > rm -f OOSERV-LOG.bak > mv -f $OO_LOG OOSERV-LOG.bak ### Backup previous logfile > echo Starting $OO_SERVER -- see $OO_LOG for details > exec $OO_SERVER -headless -accept="$OO_ACCEPT" $OO_FLAGS < /dev/null > > $OO_LOG 2>&1 & > > The running Openoffice server leaves a socket for communications in /tmp by > default (perhaps this is the reason why the OpenOffice server must be the > same user as the java webserver??): > > srwxr-xr-x 1 tomcat tomcat 0 2009-01-27 17:57 > /tmp/OSL_PIPE_91_SingleOfficeIPC_cabcdef0123456789abcd= > > To automate startup of the OpenOffice server on boot, consider using the SysV > init runlevel > system<http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/ref-guide/s1-boot-init-shutdown-sysv.html>and > a script like > /etc/init.d/openoffice<http://little.bluethings.net/2008/05/30/automating-document-conversion-in-linux-using-jodconverterooo/> > . > ... nmayer | 2009/01/22 02:14 > IMHO, it would be a significant improvement if the OpenOffice server could > run as a different user than the one which runs the web-container, such as > 'tomcat' on fedora 10. The entire reason you want to run tomcat as a > lower-privilege user is specifically to give it a "container" to run in, in > which it has less chance of accidentally overwriting some other part of the > system configuration, such as the port-80 webserver's configuration. By the > "principle of least privilege" we want Java/Web-Container stuff running as a > low-priv user (100<499) that can only bind nonprivileged ports. That's why > tomcat runs on port 8080 or 8000 and you use Apache httpd and mod_jk etc to > provide a "secure" front for Java that sysadmins have approved for use on > privileged ports like port 80. > > Also, by the principle of least priviledge and reduction of overlapping > concerns, low privilege users such as 'tomcat' should only be able to write > to a very specific part of the filesystem. Likewise a different user, e.g. > 'ooserv' in the example above, should be the only user able to write in > /home/ooserv and be the user running the OpenOffice server. If someone > "hacks" via the OpenOffice server importer, at best they'll be able to get > it to write some data into /home/ooserv, but it will not be able to change > which web-apps are deployed on your server. The latter could potentially > happen, in theory, because the OpenOffice server is running as same user as > the Java web conainer. > > There's no reason for this either. The openoffice server should be able to > accept connections from any other process on the system given that it is > listening on localhost, per the "socket,host=127.0.0.1,port=8100;urp;" > setting. > -- Niels http://nielsmayer.com _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
