Commons Dbcp
  1. Commons Dbcp
  2. DBCP-177

[dbcp] redesign to use dbcp with security manager

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.0
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

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

        Activity

        No work has yet been logged on this issue.

          People

          • Assignee:
            Unassigned
            Reporter:
            Gernot Pfingstl
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development