Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8129575

Equal DelegationPermission instances may return different hash codes

    Details

    • Subcomponent:
    • Introduced In Build:
      b69
    • Introduced In Version:
      9
    • Resolved In Build:
      b71
    • Verification:
      Verified

      Backports

        Description

        A string which contains a number of principals can be passed to constructor of DelegationPermission. The class parses this string, and extracts principals. But hashCode() method in DelegationPermission uses Permission.getName() to calculate a hash:

        http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/467094c6081b/src/java.security.jgss/share/classes/javax/security/auth/kerberos/DelegationPermission.java#l182

        ...
            public int hashCode() {
                return getName().hashCode();
            }
        ...

        Permission.getName() method returns the original string which was passed to constructor. As a result, semantically equal instances of DelegationPermission may return different hash codes. A test in the webrev below reproduces the problem.

        When JDK-8065942 was integrated, a problem may occur during permission check. If code has an appropriate DelegationPermission in policy file, AccessController may not take it into account because KrbDelegationPermissionCollection.implies() now uses ConcurrentHashMap.containsKey():

        http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/467094c6081b

        ...
        + @Override
             public boolean implies(Permission permission) {
                 if (! (permission instanceof DelegationPermission))
        - return false;
        + return false;
         
        - synchronized (this) {
        - for (Permission x : perms) {
        - if (x.implies(permission))
        - return true;
        - }
        - }
        - return false;
        -
        + // if map contains key, then it automatically implies it
        + return perms.containsKey(permission);
             }
        ...

        As a result, ACE may be thrown even if code has a correct permission in policy file.

        The following patch seems to fix the issue:

        http://cr.openjdk.java.net/~asmotrak/delegation_permission/webrev.00/

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  asmotrak Artem Smotrakov
                  Reporter:
                  asmotrak Artem Smotrakov
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  4 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved: