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

        Gernot Pfingstl created issue -
        Henri Yandell made changes -
        Field Original Value New Value
        issue.field.bugzillaimportkey 35053 12342260
        Henri Yandell made changes -
        Key COM-2108 DBCP-177
        Component/s Dbcp [ 12311109 ]
        Project Commons [ 12310458 ] Commons Dbcp [ 12310469 ]
        Assignee Jakarta Commons Developers Mailing List [ commons-dev@jakarta.apache.org ]
        Affects Version/s unspecified [ 12311647 ]
        Phil Steitz made changes -
        Bugzilla Id 35053
        Fix Version/s 1.3 [ 12311977 ]
        Phil Steitz made changes -
        Fix Version/s 1.3 [ 12311977 ]
        Fix Version/s 1.4 [ 12312615 ]
        Sebb made changes -
        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 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.
        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.*)?
        Phil Steitz made changes -
        Fix Version/s 2.0 [ 12313721 ]
        Fix Version/s 1.4 [ 12312615 ]
        Mark Thomas made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Phil Steitz made changes -
        Status Resolved [ 5 ] Closed [ 6 ]

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development