Actually the impact on revoke() isn't as bad as it seems, the
ProtectionDomain can be used to retrieve the ClassLoader to check
against implies() based on ClassLoader.
So both behaviours can be provided by perhaps using a System variable.
What are the consequences of narrowing the implies() to only check the
PermissionDomain and not expand out to encompass all PermissionDomain's
within a ClassLoader as is the current behaviour of DynamicPolicyProvider?
ClassLoaders are used as a cheap form of subprocess isolation, a
ClassLoader that contained more than one ProtectionDomain might be
utilised to package a known partially trusted, signed package from a
codebase, along with a proxy with it's own untrusted codebase. That
trusted piece of code might be used privately by the proxy to perform
some function that requires static variables, so cannot be shared with
other proxy's. That would allow you to grant a permission to the
partially trusted ProtectionDomain within the proxy's ClassLoader, via
the a CodeSource grant.
In DynamicPolicyProvider's current form, the proxy would inherit the
permissions of the trusted piece of code, the additional power of not
granting the proxy trust at all, instead allowing it to bundle a trusted
piece of code to perform a function in the same ClassLoader but in
another ProtectionDomain, might solve any number of future problems,
such as that experienced by Neuromancer with RemoteReference and proxy
trust.
Cheers,
Peter.
Peter Firmstone wrote:
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.
