I'm curious about an original design decision made in DynamicPolicyProvider.
Currently implies(PermissionDomain, Permission) is expanded to encompass
all Permissions granted to a particular ClassLoader that satisfies a
particular Principal[] array.
I'm curious about the reason for doing so, in my
ConcurrentDynamicPolicyProvider implementation I chose to have
permissions tied to a particular CodeSource or ProtectionDomain.
The two remaining qa tests that fail (all jtreg tests pass) are directly
related to the spec for DynamicPolicyProvider.
GrantPrincipal.td
GrantNoPrincipalCase02.td
No services or anything functional fail, only the spec implementation.
A SecureClassLoader can have multiple CodeSources and
ProtectionDomains. There is no way of asking the ClassLoader for these.
Typically most Service proxy's are packaged in a single jar file, it
seemed logical to me that someone might want to grant some permissions
based on a CodeSource and it's Signers (developers) and additional
permissions based on the Principals (user or node).
These might exist in separate ClassLoaders or ProtectionDomains.
Right now I'm thinking about changing my use of ProtectionDomain for
ClassLoader, however this goes against my instincts.
The difficulty arises when I want to revoke permissions based on a
codebase (a vulnerability in the code, the developers keys are still
good though) and determining which ClassLoaders are using them. Example
of use: RemoteEvent from a trusted Principal advising of a CodeSource
vulnerability that can be fixed with a simple Permission revoke on the fly.
It's very easy to remove grants based on CodeSource or PermissionDomain,
a ProtectionDomain is unique to a particular ClassLoader, however the
CodeSource may be loaded in multiple.
Is anyone using dynamic grants for multiple PermissionDomains (which
logically means multiple CodeSource's too) in their proxy's?
If I change the spec, it doesn't look like much will break, but that's a
pretty drastic measure.
The new implementation DynamicPolicyProvider uses pluggable SPI, so we
could keep around a compatible implementation of the old behaviour in
case of breakage.
