Derby
  1. Derby
  2. DERBY-2470

No authentication required to restore a backup

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 10.2.2.0
    • Fix Version/s: None
    • Component/s: Tools
    • Environment:
      Java 1.6.0-b105
      Linux 2.6.20 i686
    • Urgency:
      Normal
    • Bug behavior facts:
      Security

      Description

      My Derby has following properties set:

      derby.connection.requireAuthentication=true
      derby.authentication.provider=BUILTIN
      derby.database.defaultConnectionMode=noAccess
      derby.database.fullAccessUsers=foo
      derby.user.foo=bar

      If I'll execute a restore statement from ij the backup will be restored plus it gives an authentication error:

      ij> connect 'jdbc:derby:sample;restoreFrom=backup1';
      ERROR 08004: Connection refused : Invalid authentication

      If I add the user and password arguments to the url then the restore works as before without the error message.

        Issue Links

          Activity

          Juha Heljoranta created issue -
          Rick Hillegas made changes -
          Field Original Value New Value
          Link This issue is related to DERBY-2264 [ DERBY-2264 ]
          Hide
          Rick Hillegas added a comment -

          This looks very similar to the problems which Dag has encountered working with authentication and shutdown/encryption/upgrade on DERBY-2264.

          Show
          Rick Hillegas added a comment - This looks very similar to the problems which Dag has encountered working with authentication and shutdown/encryption/upgrade on DERBY-2264 .
          Hide
          Dag H. Wanvik added a comment -

          Discussed this issue a bit with Rick off line, and came to the conclusion
          that this action should probably be protected by system privileges. The reasoning is
          as follows: a) If there is no database at the url location, this is really a create database
          operation. b) if there is an existing database in the url location, the operation involves
          more than a single database: Only the latter seems the right scope for database level
          privileges.

          If one did consider checking against database level (owner) privileges, which database
          image should determine the ownership of the database, the backup or the url image?
          (While we can not change ownership right now, that might change.)
          It seems cleaner to me to make this a system level privilege (DERBY-2109).

          Linking this issue to DERBY-2109 for reference.

          Show
          Dag H. Wanvik added a comment - Discussed this issue a bit with Rick off line, and came to the conclusion that this action should probably be protected by system privileges. The reasoning is as follows: a) If there is no database at the url location, this is really a create database operation. b) if there is an existing database in the url location, the operation involves more than a single database: Only the latter seems the right scope for database level privileges. If one did consider checking against database level (owner) privileges, which database image should determine the ownership of the database, the backup or the url image? (While we can not change ownership right now, that might change.) It seems cleaner to me to make this a system level privilege ( DERBY-2109 ). Linking this issue to DERBY-2109 for reference.
          Dag H. Wanvik made changes -
          Link This issue is related to DERBY-2109 [ DERBY-2109 ]
          Dag H. Wanvik made changes -
          Derby Categories [Security]
          Dag H. Wanvik made changes -
          Component/s Security [ 11411 ]
          Dag H. Wanvik made changes -
          Component/s Tools [ 11414 ]
          Hide
          Rick Hillegas added a comment -

          Triaged for 10.5.2: assigned normal urgency.

          Show
          Rick Hillegas added a comment - Triaged for 10.5.2: assigned normal urgency.
          Rick Hillegas made changes -
          Urgency Normal
          Kathey Marsden made changes -
          Labels derby_triage10_5_2
          Rick Hillegas made changes -
          Link This issue relates to DERBY-866 [ DERBY-866 ]
          Hide
          Rick Hillegas added a comment -

          Linking this issue to DERBY-866. The discussion there may shed light on how to address this issue.

          Note that this vulnerability can be used to copy any database out of Derby-managed directories into public directories. The copied database can then be cracked and inspected.

          Right now, authentication is performed AFTER the database is restored. My current thinking is that the fix to this vulnerability involves performing authentication BEFORE the database is restored, possibly followed by a second round of authentication AFTER restoration finishes. This has consequences for DERBY-866.

          Show
          Rick Hillegas added a comment - Linking this issue to DERBY-866 . The discussion there may shed light on how to address this issue. Note that this vulnerability can be used to copy any database out of Derby-managed directories into public directories. The copied database can then be cracked and inspected. Right now, authentication is performed AFTER the database is restored. My current thinking is that the fix to this vulnerability involves performing authentication BEFORE the database is restored, possibly followed by a second round of authentication AFTER restoration finishes. This has consequences for DERBY-866 .
          Hide
          Rick Hillegas added a comment -

          Note that if you have system-level authentication turned on, then the RESTORE can only be performed by a user who has system-wide credentials. What is missing at this point is some way to control the privileges of system-wide users. Right now, any use with system-wide privileges has the power to create/restore databases as well as the power to shutdown the whole engine.

          Show
          Rick Hillegas added a comment - Note that if you have system-level authentication turned on, then the RESTORE can only be performed by a user who has system-wide credentials. What is missing at this point is some way to control the privileges of system-wide users. Right now, any use with system-wide privileges has the power to create/restore databases as well as the power to shutdown the whole engine.
          Gavin made changes -
          Workflow jira [ 12399980 ] Default workflow, editable Closed status [ 12802109 ]

            People

            • Assignee:
              Unassigned
              Reporter:
              Juha Heljoranta
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:

                Development