commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sebb (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DBCP-177) [dbcp] redesign to use dbcp with security manager
Date Fri, 08 Jan 2010 17:58:54 GMT

     [ https://issues.apache.org/jira/browse/DBCP-177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Sebb updated DBCP-177:
----------------------

    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.*)?

  was:
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.


Remove some duplicated copy-n-paste

> [dbcp] redesign to use dbcp with security manager
> -------------------------------------------------
>
>                 Key: DBCP-177
>                 URL: https://issues.apache.org/jira/browse/DBCP-177
>             Project: Commons Dbcp
>          Issue Type: Improvement
>         Environment: Operating System: All
> Platform: All
>            Reporter: Gernot Pfingstl
>            Priority: Minor
>             Fix For: 1.4
>
>
> 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.*)?

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message