This bug does not manifest itself with default settings as the bug is in SubjectDomainCombiner.combineJavaxPolicy (i.e. when JAAS policy provider is set).

The main issue is that when combineJavaxPolicy creates the new ProtectionDomains, it fails to take code-based grants into consideration. This was not an issue in JDK1.3 as SecureClassLoader sets static (code-based) Permissions at load time (thus ProtectionDomain.getPermissions() + javax.security.auth.Policy.getPolicy().getPermissions() would suffice), but with dynamic policy support in JDK1.4 we now have an issue as [1] ProtectionDomain.getPermissions() by default returns an empty PermisisonCollection instance and [2] javax.security.auth.Policy.getPolicy().getPermissions() only evaluates principal-based grants [3] combineJavaxPolicy constructs ProtectionDomain instances using the 2-arg argument(i.e. staticPermissions field would be set to true), so when AccessControlContext calls ProtectionDomain.implies (in AccessControlContext.checkPermission) the Policy is not consulted at all.

The net effect is that code-based grants (even 'universal grants' that apply to all code sources and principals) are ignored during the combination process.

  To reproduce this, simply set JAAS policy provider and then add a 'universal grant' to the effective java.policy, then in the test code perform a Subject.doAsPrivileged (or Subject.doAs) with a AccessController.checkPermission for the aforementioned 'universal grant'. The checkPermission call will pass by default (using Java2 provider) and fail when JAAS policy provider is set.