commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Phil Steitz (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DBCP-177) [dbcp] redesign to use dbcp with security manager
Date Mon, 10 Jul 2006 05:22:33 GMT
     [ 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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message