On 09/03/2013 11:07 AM, Alan Bateman wrote:
On 02/09/2013 18:45, Nick Williams wrote:
:
I didn't decide to ignore the security concerns, I just don't see any
security concerns. As has been /clearly/ established in the last
three months, frameworks have been using getCallerClass for years, if
not a decade. It has never caused a security problem. Ever. If I'm
wrong, please point out to me a specific vulnerability that this has
led to.
I am not allowed to discuss any details about vulnerabilities here.
However, as a general point then caller sensitive methods have been
highly problematic in the JDK.
As regards frameworks using sun.reflect.Reflection.getCallerClass
directly then it's as I said previously, they are probably not run
with a security manager very often (at least not unless the policy is
configured to allow direct access to sun.*).
I don't have the ability to go back and start from the beginning on
something that I had the understanding was generally agreed upon
before I started.
You've done good work and no one is suggesting you throw it again.
However I don't recall any agreement on a solution, rather the
discussion mostly fizzled out. In particular I do not recall any
discussions about changing the goals of JEP 176 and make @CS a public
API. Whatever about @CS methods being a bad there is also the issue of
annotations changing runtime behavior.
I see Mandy has restarted the discussion on use-cases (thank you
Mandy) and working through these and addressing a subset initially
might be good way to move this forward. More so as this is your first
patch/contribution to OpenJDK - a first patch does not have to solve
world peace, starting out with smaller changes is good.
One fix that is very interresting IMO is to fix the way the stacktrace
is created in Throwable.
It will not solve the world peace but in the same time it will speedup
all programs that create a stacktrace,
not that bad too.
:
I'm not voicing any objection to any kind of security/permissions
checks in these methods. Before I can pass judgement one way or
another, I'd want to know 1) specifically what type of permissions
check you are looking for, and 2) what you're looking to achieve with
said permissions check.
I would say this is TBD and start by asking the question as to whether
there are concerns about leaking reference to Class objects that
untrusted code wouldn't normally be able to get a reference to. Tom
brings up the cost of the permission check and also whether any API
should be tied to class loader. There are clearly discussion points
here that could potentially influence the API.
-Alan.
Rémi
