[ http://issues.apache.org/jira/browse/DBCP-177?page=all ]
Phil Steitz updated DBCP-177: ----------------------------- Bugzilla Id: (was: 35053) Fix Version: 1.3 > [dbcp] redesign to use dbcp with security manager > ------------------------------------------------- > > Key: DBCP-177 > URL: http://issues.apache.org/jira/browse/DBCP-177 > Project: Commons Dbcp > Type: Improvement > Environment: Operating System: All > Platform: All > Reporter: Gernot Pfingstl > Priority: Minor > Fix For: 1.3 > > 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 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.*)? > ------- 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. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]