[kaffe] java.lang.IllegalAccessError

[Chris Gray]

This is an aspect of a known security misfeature of inner classes: some=20
access controls which are enforced by the compiler cannot be enforced by =
the=20
VM with the same granularity, because the VM doesn't really grok the=20
inner/outer class hierarchy.  E.g from=20
<http://www.lsd-pl.net/documents/javasecurity-1.0.0.pdf>:

<blockquote>In the case where system classes use inner classes, these inn=
er=20
classes can be accessed from anycode in the same package. This is due to =
the=20
fact that Java bytecode has no concept of inner classes,so they are=20
translated by the compiler into ordinary classes. Besides, inner classes =
are=20
allowed toaccess private fields of the outer classes. This is caused by t=
he=20
fact that they are always translatedinto separate classes. Therefore, in=20
order to let the inner class access the fields of the correspondingouter=20
class, the compiler silently changes these fields from private to package=
=20
scope.
</blockquote>

Chris

On Saturday 25 October 2003 17:07, Guilhem Lavaux wrote:
> Helmer Kr=E4mer wrote:
> >On Fri, 24 Oct 2003 20:14:38 +0200
> >Guilhem Lavaux <guilhem@kaffe.org> wrote:
> >
> >Hi Guilhem, hi Ito,
> >
> >>>The attached programs cause java.lang.IllegalAccessError,
> >>>which partly seemes to have something to do with KJC,
> >>>but class files compiled with Sun's javac also cause the
> >>>error.
> >>
> >>Apparently KJC choses to protect the inner class (as usual). I've not
> >>really seen a specific restriction about access modifiers concerning
> >>inner classes in doc but the JDK's compiler put your sample class in
> >>public access (even though you explicitly specified it protected). Th=
e
> >>best guess I can make is to ignore the access modifier for inner clas=
ses
> >>in KJC. I'll prepare this for tomorrow.
> >
> >I don't think that this would be the correct fix (altering
> >the access modifiers during compilation doesn't look right
> >to me). For a discussion of a similar problem have a look
> >at the thread starting at this mail:
> >
> >http://groups.google.com/groups?hl=3Den&lr=3D&ie=3DUTF-8&selm=3DPine.L=
NX.4.10.1001
> >0111327040.12800-100000%40green.usr.onet
> >
> >I think the real problem is kaffe's runtime access checking,
> >which is why I'm about to check in the following patch:
>
> Yes, but this doesn't solve the problem concerning JDK. If you
> disassemble the code generated
> from the classes provided by Ito you may notice that the inner class
> doesn't have any protection
> although it is protected. But I've made another test with private and
> apparently it changes something also
> concerning the modifier, so the problem should be more complicated.
>
> Cheers,
> Guilhem.
>
>
>
> _______________________________________________
> kaffe mailing list
> kaffe@kaffe.org
> http://kaffe.org/cgi-bin/mailman/listinfo/kaffe

--=20
Chris Gray                                /k/ Embedded Java Solutions
Embedded & Mobile Java, OSGi              http://www.kiffer.be/k/
chris.gray@kiffer.be                      +32 477 599 703