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

        Hide
        Sebb added a comment -

        Remove some duplicated copy-n-paste

        Show
        Sebb added a comment - Remove some duplicated copy-n-paste
        Hide
        Mark Thomas added a comment -

        I really don't know what to say about how long this has taken to fix. Sorry doesn't really cut it.

        I have just committed the fix for this for DBCP 2. I have only been testing with my fairly basic database application. We may need to pre-load a few more classes to prevent AccessControlExceptions for all use cases. DBCP 2 is feeding in the Tomcat 8 beta releases so we should get some good feedback from those.

        Show
        Mark Thomas added a comment - I really don't know what to say about how long this has taken to fix. Sorry doesn't really cut it. I have just committed the fix for this for DBCP 2. I have only been testing with my fairly basic database application. We may need to pre-load a few more classes to prevent AccessControlExceptions for all use cases. DBCP 2 is feeding in the Tomcat 8 beta releases so we should get some good feedback from those.

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development