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
