While checking tomcat with security, I noticed the following in server.xml:
"If security manager is enabled, you'll have read perms.
in the webapps dir and read/write in the workdir."
I quote this because this question was made by David some time ago.
The set of properties needed for Jetspeed to run with security on
under tomcat 3.2.1 and turbine close to cvs HEAD is (approx.):
grant codeBase "file:${tomcat.home}/webapps/jetspeed" {
//I'm not sure about this one is needed
permission java.io.FilePermission
"${tomcat.home}/webapps/jetspeed/WEB-INF/-", "read";
//Possitively yes (TR.p include using relative path)
permission java.io.FilePermission "JetspeedResources.properties",
"read";
//Needs delete to handle DB
permission java.io.FilePermission
"${tomcat.home}/webapps/jetspeed/WEB-INF/db/*", "read,write,delete";
permission java.io.FilePermission
"${tomcat.home}/webapps/jetspeed/WEB-INF/cache/*", "read,write,delete";
permission java.io.FilePermission
"${tomcat.home}/webapps/jetspeed/WEB-INF/log/*", "read,write,delete";
//Possibly redundant
permission java.io.FilePermission
"${tomcat.home}/webapps/jetspeed/WEB-INF/psml/*", "read,write,delete";
//To be able to send mail (not tested)
permission java.net.SocketPermission "localhost:25","connect";
//To be able to run cache and feeds
permission java.net.SocketPermission "*","connect";
//To be able to say setFollowRedirects() in cache code
permission java.lang.RuntimePermission "setFactory";
//Xalan needs this to check for Extensions...
permission java.lang.RuntimePermission "getClassLoader";
//Turbine needs this (TurbineServletService) to handle servlet2.0
//Turbine needs this to get RunDatas from Factory
permission java.lang.RuntimePermission "accessDeclaredMembers";
//The way we ask for permissions in admin portlet...
permission java.util.PropertyPermission "*", "read,write";
//Castor will fail if this is not here...
permission java.io.FilePermission
"${java.home}/lib/castor.properties", "read";
//For jaxp
permission java.io.FilePermission
"${java.home}/lib/jaxp.properties", "read";
};
I'm not completely sure about all the permissions, but this gives an
idea of the complexity of having Jetspeed running under a security
managed servlet container. I had to do some debugging to find some of
the permissions needed... There could be "hidden" permissions, that I
have not found yet. Note that most of these permissions do not surface
in the Jetspeed.log, as we don't always test for RuntimeErrors and some
errors are wrapped.
The debugging allowed me to find a solution for the "proxy" problem, at
least for jdk1.3.1beta (I don't know if it was there in older jdks, but
it may be worth try). http.nonProxyHosts sets hosts for which there is
no proxy, http.proxyHost is the proxy for http, proxyHost is the generic
proxy. This are the security checks while the cache refreshes an entry:
access: access allowed (java.net.SocketPermission network54.com resolve)
access: access allowed (java.net.SocketPermission 64.70.16.71:80
connect,resolve)
access: access allowed (java.util.PropertyPermission http.nonProxyHosts
read)
access: access allowed (java.util.PropertyPermission http.proxyHost read)
access: access allowed (java.util.PropertyPermission proxyHost read)
(use -Djava.security.debug=access /all for a very verbose log)
That's all folks!
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/jetspeed@list.working-dogs.com/>
List Help?: [EMAIL PROTECTED]
