Re: Reminder: Illegal Package-Private Accesses in libgcj

[Andrew Haley <aph at redhat dot com>]

Bryce McKinlay writes:
 > On Nov 3, 2003, at 5:59 PM, David Daney wrote:
 > 
 > > Ranjit Mathew wrote:
 > >
 > >> But Bryce wants to avoid having to call backtrace( )
 > >> and use libgcc's unwinder interface instead and hence
 > >> my query.
 > >>
 > >> Ranjit.
 > >>
 > >>
 > > Well you probably already know this, but a few weeks ago I added 
 > > libjava/sysdep/dwarf2-backtrace.cc which as its name implies generates 
 > > a backtrace via the libgcc unwinder.  However as was noted earlier, 
 > > this is of little use when the eh_frame info is not available.
 > >
 > > It seems to me that if there is no other way to get a backtrace than 
 > > using -fno-omit-framepointer and walking the stack, then that is what 
 > > you have to do.
 > >
 > > The alternative is to not be able to get a stack trace, which implies 
 > > that much of the java security infrastructure will not work.
 > 
 > Theres actually a bit more required than just a simple backtrace to
 > get the security stuff right. We also need the entry point of the
 > function, in order to match it up with a java.lang.Class and
 > _Jv_Method, and the libgcc unwinder conveniently gives us
 > this. Using something like dladdr() and demangling the function
 > name is an alternative approach, and the existing code does that,
 > but it seems fragile and isn't correct from the security
 > perspective - for example someone could simply call their class
 > java.lang.Whatever and get elevated privileges.

It's clearly better to use the reflection data to do this job.  Note
that the *only* reason I didn't throw away all the business of calling
an external addr2line a long while ago is that people were (and
presumably still are) keen on getting line numbers in stack traces.

The existing code used for walking the stack to get a security context
already does what you're suggesting -- it generates a hash table of
ncode values and uses it to find the class of a call frame.  The only
case in which this fails to work is where a method is defined in a
compilation unit other than that of the class to which it belongs, and
the only time that happens is in native code.

So, what are you proposing to do that's really different?  Please
explain, and let us discuss the implications before we go any further.

Andrew.