Details
-
Improvement
-
Status: Closed
-
Minor
-
Resolution: Fixed
-
None
-
None
-
Operating System: All
Platform: All
-
35053
Description
Dbcp is not designed to run with security manager, especially when dbcp is used
in a servlet container (like tomcat) there are problems to set up security
policy in a correct manner.
e.g.: to get a connection should be completely transparent to the (web)app -
only dbcp should know how to get the datasource/connection. If the connection
uses tcp (which will be in the most cases) only dbcp should be granted a socket
permission. The app itself should not be granted this permission - the app
should not be able to connect the dbserver itself.
So dbcp needs some "doPrivileged()".
see Bug 35034:
Running tomcat with security manager: To get a datasource (with jndi) and to use
statements you have to grant several accessClassInPackage Permissions to tomcat
internal packages to the webapp:
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";
Additionally dbcp needs a permission java.lang.RuntimePermission
"getClassLoader"; permission to load the jdbc driver.
And in most cases you need some socket permissions.
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. The app is not interested in the details how the container will get
the connection - it is only interested to have a connection.
There is no need 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.*)?
------- Additional Comment #1 From Remy Maucherat 2005-05-24 09:58 [reply] -------
The commons-dbcp library would need to be written with the security manager in
mind (ie, it needs to have PAs). Not a Tomcat bug, and you should be able to use
alternate datasource providers.:
Running tomcat with security manager: To get a datasource (with jndi) and to use
statements you have to grant several accessClassInPackage Permissions to tomcat
internal packages to the webapp:
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";
Additionally dbcp needs a permission java.lang.RuntimePermission
"getClassLoader"; permission to load the jdbc driver.
And in most cases you need some socket permissions.
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. The app is not interested in the details how the container will get
the connection - it is only interested to have a connection.
There is no need 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.*)?