On Sep 3, 2013, at 4: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.
Well so much for being open.
However, as a general point then caller sensitive methods have been highly
problematic in the JDK.
If security issues aren't allowed to be discussed in the open then how can we,
the community, help address them? You say my patch has security problems. I
haven't seen any detailed yet.
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'd argue that Logback, Log4j, and Groovy, three of the most common Java
framework around, are very likely used with security managers quite often. It
doesn't cause any problems because we don't misuse the information we obtain
from getCallerClass.
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.
We reached a point where a few people said the API looked good, and then someone said
that hands were short and "patches are welcome." I was then given guidelines
for submitting a patch. Doesn't sound like fizzling out to me.
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.
If applications want to change their behavior based on the caller, let them! Is
it bad practice, bad design, and likely all kinds of dumb? Heck yea. But there
are legitimate uses of this. Just because there are bad uses of this feature
doesn't mean you must omit it. If that's the case, then we need to get rid of
all input/output in Java--it could be used to write viruses to the file system!
Oh, and we should remove Random, too, because applications might Randomly
change their behavior! We must protect people from their own mistakes.
One way the JVM uses getCallerClass, if I understand correctly, is to detect if
the code executing a certain method is allowed to. Would you deny the same
ability to applications written for the JVM? And, of course, logging frameworks
are the obvious exception. Think of the performance improvements that could be
had if, while determining the source of an event, loggers could get the exact
one frame they needed (via StackTraceFrame#getCallerFrame, ~100ms per 1,000,000
calls) instead of having to generate an entire stack trace and loop through it
to find the one frame (Thread#getStackTrace(), ~3,000ms per 1,000,000 calls).
I see Mandy has restarted the discussion on use-cases (thank you Mandy)
Sounds like starting over to me.
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.
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.
As I have said before, there are MANY ways to get a Class object that aren't
security checked. It's when you try to USE that class object to impersonate it
or invoke methods that security checks begin to happen. As they should!
Nick
