Re: Patch: FYI: remove redundant test

[Andrew Haley <aph at redhat dot com>]

Tom Tromey writes:
 > >>>>> "Andrew" == Andrew Haley <aph@redhat.com> writes:
 > 
 > Andrew> I'd like to suggest this alternative patch.  It removes the
 > Andrew> arbitrary upper limit on scanning the stack and catches the
 > Andrew> ArrayIndexOutOfBoundsException.  On the other hand, perhaps
 > Andrew> the upper limit of 6 is so that we can handle interpreter and
 > Andrew> native methods.  Is it okay for the invocation API when
 > Andrew> interpreted?
 > 
 > I forgot about reflection :-(.  You're right, we must handle that
 > correctly.
 > 
 > Andrew> Maybe we ought to define getCallingClass() as a macro or an inline
 > Andrew> method in a header file to avoid this repetition.
 > 
 > Sounds good.  Want to write it?

Okay.

 > Andrew> I'm beginning to wonder if we ought to throw a security
 > Andrew> exception if we don't find the class.  This is for targets
 > Andrew> that support backtrace(), post 3.3 branch.
 > 
 > When we're looking for the class loader, I don't think so.  In fact,
 > even searching the way we do right now is a bit bogus.  Really we just
 > want to find the caller (skipping "synthetic" frames like ffi and also
 > reflection stuff).  If we're being called from some random bit of C++
 > code, I suppose we could just fall back on the system class loader.  I
 > don't see how ending up with the system class loader in some unusual
 > circumstance can violate the security model.  (But I'm not an expert
 > there either.)

Well, the trouble here is that sometimes we want to be very secure and
sometimes we don't.  It we write something that works for top security
and is reliable, as long as it's not too expensive we can use it
everywhere.

 > When we're looking at the caller for SecurityManager, then if we can't
 > find the answer it might be correct to throw a security exception.  It
 > isn't clear.  I think it depends on the possible reasons that stack
 > tracing can fail.

Indeed.  More study needed.

Andrew.