On 09/02/2013 03:56 PM, Tom Hawtin wrote:
On 02/09/2013 09:33, Alan Bateman wrote:
From a quick scan then it appears that you've decided to ignore the
security concerns so I don't think anyone can (or should) sponsor this
patch until there is further discussion on the API and the security
implications.
I've barely looked through the patch, let alone audited it. However:
As the method appears to be mostly for tracing, performing a security
check per invocation is likely to hurt performance. Unless it was
caller sensitive (which seems to be equated with Bad Practice these
days) it would also require a doPrivileged block. Much better to
perform a single security check when acquiring a capability object, in
a similar(ish) way to sun.misc.Unsafe or SharedSecrets.
In order to work with less privileged code, it may also be worthwhile
to provide a version of the capability object parameterised with a
class loader. If code has access to a ClassLoader object, then it is
consistent for it to be given access to Classes loaded by it or child
loaders, and in practice from parent loaders (but not children of
parents).
Security relating to Class objects is "interesting". The genuine
security issue with Class objects is that they have are an attenuation
of the capability of their ClassLoader. There are many ways to acquire
Class objects. Some have confusing defence-in-depth security; some,
such as Object.getClass used for quick null checks, do not.
Tom
I wonder if a java.lang.invoke.MethodHandles.Lookup is not a better
object than a ClassLoader for a capability object.
Rémi
