Illegal Package-Private Accesses in 3.4
Bryce McKinlay
bryce@mckinlay.net.nz
Mon Aug 11 06:45:00 GMT 2003
On Monday, Aug 11, 2003, at 09:23 Pacific/Auckland, Mark Wielaard wrote:
> Hi (discussion moved from java to java-patches),
>
> On Wed, 2003-07-09 at 21:35, Ranjit Mathew wrote:
>> I applied my package-private access checking patch/kludge to
>> the 3.4 snapshot from 2007-07-02 and found that some of the
>> issues I had reported earlier in 3.3 have been resolved while
>> a new one has been added.
>>
>> The issues still present are:
>>
>> 2. java.lang.VMThrowable illegally calls "stackTraceAddrs( )"
>> in gnu.gcj.runtime.StackTrace.
>
> It seems to me that the best thing to do is to move StackTrace to the
> java.lang package and make it package private to prevent any 'illegal'
> access to this class by user code.
Lets have a look at where stackTraceAddrs() is being used in
VMThrowable:
NameFinder nameFinder = new NameFinder();
result = nameFinder.lookup(t, trace.stackTraceAddrs(),
trace.length());
Since NameFinder and StackTrace are both in the same package, wouldn't
a simpler solution be to pass "trace" itself and have NameFinder call
the stackTraceAddrs?
It would be cleaner to keep these things in the same package wherever
possible. If we're worried about user code calling NameFinder being a
security risk, we could add a security check to its constructor.
BTW, I notice some evil use of RawData & _Jv_Malloc in StackTrace.
Specifically I don't see 'addrs' getting freed anywhere! I think its
better to avoid RawData wherever possible, and use byte[] instead. And
maybe we should ban _Jv_Malloc from libgcj to enforce this ;-)
Regards
Bryce.
More information about the Java-patches
mailing list