5.5.9 & security manager

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

5.5.9 & security manager

Pfingstl Gernot
I'm trying to run my apps with security manager and I noticed some (in my opinion) strange things:

The simple JSP
causes an "access denied (java.lang.RuntimePermission accessClassInPackage.org.apache.tomcat.util.net)" exception. Of course putting "accessClassInPackage.org.apache.tomcat.util.net" in my policy file causes that my JSP works well. But isn't this an implementation detail of tomcat that should be hidden to a developer/admin? No non trivial web app will work without this permission - why do you put "org.apache.tomcat" into "package.access" in file catalina.properties by default? This does not make sense, because when running without security manager, this entry will be ignored, when running with security manager, no web app will work!?
So there following possibilities:
1) change default catalina.properties file ("package.access")
2) change default catalina.policy file to add this permission to all code bases
3) respose methods (and all other similar) must use "doPrivileged()"

Obtaining a datasource with JNDI has similar problems:
Getting a sql connection requires following permissions for the whole app (correctly spoken for this pieces which uses sql, but practically this is the whole app):
      permission java.lang.RuntimePermission "getClassLoader";
      permission java.lang.RuntimePermission "accessClassInPackage.org.apache.tomcat.dbcp.collections";
      permission java.lang.RuntimePermission "accessClassInPackage.org.apache.tomcat.dbcp.pool.impl";
      permission java.lang.RuntimePermission "accessClassInPackage.org.apache.tomcat.dbcp.dbcp";
      permission java.lang.RuntimePermission "accessClassInPackage.org.apache.tomcat.dbcp.pool";
      permission java.net.SocketPermission "xxxx:9999", "connect,resolve";

Datasources will be made available by the container (with JNDI). So the app doesn't matter where the database resides nor how the container makes the connection. I'm not interested in the details how the container will get the connection - I'm only interested to have a connection.
I don't want to give the whole app a permission to connect to some server only because the container wants to make some connection to this server. The permission if a app should be able to make a connection is given by a resource-link entry in context.xml.
The permission to connect to the database server should be given at the container level and only there.
Why should the whole app have permission to access tomcat internal packages (org.apache.tomcat.*)?
So a doPrivileged() blocks will be neccessary.

Is this a general rule when working with tomcat with security manager to expose internal classes to the web apps or is there a better solution I havn't found?


To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]