On 30/09/16 15:11, Sanne Grinovero wrote:
> Hi all,
> I think what Peter raises is a very interesting quandary.
>
> Without going in the syntax details of this proposal, the point is
> that implementations of "javax.persistence" (and similar APIs) need to
> advertise themselves as eligible to getting certain additional
> privileges - such as reflective access - which the platform is
> attempting to limit (why?).
>
> The problem I see is that it should be fairly easy for any library to
> fool the platform to obtain the same privileges; I could certainly
> extend Hibernate and make a new JPA provider in just minutes, and do
> something else with those additional privileges as well.
> This might be a clumsy trick, but sufficiently motivated people - such
> as those having malicious intents - could certainly entertain such
> plans.
> While well intentioned developers who have a legitimate reason to need
> reflective access - like plans to make some better framework ? - would
> need to write odd looking, time wasting code to get their work done.
This assumes that malicious code can get into the classpath in the first
place. Of course, if you don't (cannot?) control what gets into your
classpath you are fairly much skewered already.
Also, although this solution leaves a window ajar it doesn't leave every
opening in the fabric of the building wide open. I think the main
concern here is therefore how much this provides room for accidental
transgression, rather than any question of protection from malicious
larceny -- the latter being more an academic question of how game over
exactly over is "game over".
> Wouldn't it be far easier to just allow reflective access to everyone
> without restrictions, at least on weak modules? I'm not seeing the
> benefits of preventing this - especially to people using the
> Reflection API.
One benefit of limiting reflection is the ability to decide precisely
what can or cannot be be accessed and in the former case where it can or
cannot happen. That's certainly important for analyses which may help
performance optimization.
regards,
Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
