Derby
  1. Derby
  2. DERBY-3333

User name corresponding to authentication identifier PUBLIC must be rejected

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.2.2.0, 10.3.1.4, 10.3.2.1, 10.4.1.3
    • Fix Version/s: None
    • Component/s: SQL
    • Urgency:
      Normal
    • Issue & fix info:
      Release Note Needed
    • Bug behavior facts:
      Security

      Description

      SQL Standard (foundation) says:

      Section 5.4 SR 20) No <authorization identifier> shall specify "PUBLIC".

      This is a syntax rule which implies a 42xxx SQL state but I wonder if 'invalid authorization specification.' (28xxx) makes more sense?
      Maybe it's 28xxx when used in a connection request and 42xxx in a SQL statement?

      Needs to be disallowed on:
      JDBC connection requests
      GRANT statements, ie. using "PUBLIC" as a delimited identifier.

      Existing application impact if the exists a user with an authorization identifier of PUBLIC in an existing system.

      1. DERBY-3333-roles.stat
        0.4 kB
        Dag H. Wanvik
      2. DERBY-3333-roles.diff
        6 kB
        Dag H. Wanvik

        Issue Links

          Activity

          Hide
          Tiago R. Espinha added a comment -

          Triaged for 10.5.2.

          Assigned Normal urgency.

          Show
          Tiago R. Espinha added a comment - Triaged for 10.5.2. Assigned Normal urgency.
          Hide
          Myrna van Lunteren added a comment -

          removing 10.5 fix flag. Only the SQL roles aspect has been changed.

          Show
          Myrna van Lunteren added a comment - removing 10.5 fix flag. Only the SQL roles aspect has been changed.
          Hide
          Dag H. Wanvik added a comment -

          Changed link to DERBY-2207 to "is related to", since the outstanding part of this issue is not particular to roles,
          but common to all grant/revoke functionality.

          Show
          Dag H. Wanvik added a comment - Changed link to DERBY-2207 to "is related to", since the outstanding part of this issue is not particular to roles, but common to all grant/revoke functionality.
          Hide
          Dag H. Wanvik added a comment -

          Changed blocks to "is depended upon", since the roles part of the issue
          is fixed, and thus the issue no longer blocks DERBY-2207 even if not fully resolved.

          Show
          Dag H. Wanvik added a comment - Changed blocks to "is depended upon", since the roles part of the issue is fixed, and thus the issue no longer blocks DERBY-2207 even if not fully resolved.
          Hide
          Dag H. Wanvik added a comment -

          Unassigning myself after commiting the fix for CREATE ROLE as partial
          solution for this issue.

          Show
          Dag H. Wanvik added a comment - Unassigning myself after commiting the fix for CREATE ROLE as partial solution for this issue.
          Hide
          Dag H. Wanvik added a comment -

          Committed as svn revision 655948 on trunk.

          Show
          Dag H. Wanvik added a comment - Committed as svn revision 655948 on trunk.
          Hide
          Dag H. Wanvik added a comment -

          Uploaded DERBY-3333-roles, which adds this check to create role, grant role and revoke role, and adds new test cases for this to RolesTest.

          Show
          Dag H. Wanvik added a comment - Uploaded DERBY-3333 -roles, which adds this check to create role, grant role and revoke role, and adds new test cases for this to RolesTest.
          Hide
          Daniel John Debrunner added a comment -

          This also applies to role names, it would be good to disallow CREATE ROLE for PUBLIC before a release, then there would be no backwards compatibility issue.

          Show
          Daniel John Debrunner added a comment - This also applies to role names, it would be good to disallow CREATE ROLE for PUBLIC before a release, then there would be no backwards compatibility issue.

            People

            • Assignee:
              Unassigned
              Reporter:
              Daniel John Debrunner
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:

                Development