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/