Access Checking for MethodHandles.Lookup broken!

Sebastian Sickelmann sebastian.sickelmann at gmx.de
Thu Nov 28 13:43:41 PST 2013


Hi,

i finally found some time to have a look at this.

I think it is a problem in MethodHandleNatives.resolve which is called
from MemberName.resolve to figure out
which MemberName is the one that should be resolved.

The wrong behavior of jdk1.7.0_17 was very usefull to find this, because
it has the same error for fields(see [0]) which
is broken for virtual method lookups in 1.7.0_45.

Let's assume we have a class Example with some private fields and
methods and an class SubExample which extends
Example. When MethodHandleNatives is called with a MemberName.clazz [2]
== SubExample.class and
the MemberName.name on private field of Example and an lookupClass ==
SubExample.class then
in 1.7.0_17 a MemberName is returned with the declaring class equals to
SubExample.class in contrary
to 1.7.0_45 where a MemberName is returned with the declaring class
equals to Example.class.

When we take a look at the same example for a lookup of a virtual method
call we see that MethodHandleNatives:
When MethodHandleNatives is called with a MemberName.clazz ==
SubExample.class and
the MemberName.name on private method of Example and an lookupClass ==
SubExample.class then
a MemberName is returned with the declaring class equals to
SubExample.class which is wrong.
SubExample isn't the declaring class of this method. And some time later
in sun.invoke.util.VerifyAccess.isMemberAccessible
it run's into this code here:
        if (defc == lookupClass)
            return true;        // easy check; all self-access is OK

which skips any further checking.


Should we file a bug for this?

-- Sebastian

[2] which should be the declaring class. But in this example it isn't.

Am 26.11.2013 18:44, schrieb Sebastian Sickelmann:
> Hi,
>
> A few days ago I thought I had found a bug in
> MethodHandles.Lookup.findGetter/findSetter[0] , but i was wrong
> it seemed to be fixed in the latest JDK7 and JDK8 versions. I search the
> Bugdatabase for a ticket relating my issue
> and didn't found one. So i looked at the regressiontests for
> java/lang/invoke in the jdk repository. I found some
> test but it doesn't seem to produce the error i had expected on my old
> jdk7-version. So i decided to add some
> additional regressiontests. See patch[1] for more information of it.
> Everything is fine. It chrashes multiple times with my old jdk7 and it
> runs almost with 1.7.0_45 and 1.8.0-ea-b109.
> But unfortunatly it runs only almost. The last testcase in
> testFindPrivate() chrashes on jdk7 and jdk8.
>
> checkIllegalAccessException(new CTROE(){ public void run() throws ReflectiveOperationException{
>     PRIV_SUBCLASS.findVirtual(SubExample.class, "pri_v0",MethodType.methodType(void.class));
> }});
>
>
> The code tries to access the private method Example.pri_v0 from an
> lookup instance of a subclass of Example.
> I expect that there should be an IllegalAccessException, but
> unfortunatly it works.
>
> Sorry for cross-posting. But i think it is more related to core-libs-dev.
>
> I would love to work on a fix of this. But it will take some days for me to take a closer look to the implementation.
>
>
> -- Sebastian
>
> [0]
> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2013-November/010148.html
> [1]
> https://dl.dropboxusercontent.com/u/43692695/oss-patches/openjdk8/MethodHandles.Lookup/hgexport_0.txt
>
>
> Am 26.11.2013 03:03, schrieb John Rose:
>> On Nov 24, 2013, at 2:08 AM, Sebastian Sickelmann
>> <sebastian.sickelmann at gmx.de <mailto:sebastian.sickelmann at gmx.de>> wrote:
>>
>>> I am sorry. Due to a configuration failure in my IDE had run with
>>> 1.7.0_16
>>>
>>> Checked this again with 1.7.0_45 and 1.8.0-ea-b109 and everything is
>>> fine.
>>>
>>> Sorry for the mailing-list noise.
>> If a MethodHandles.Lookup call allows more access to a method than its
>> corresponding bytecode behavior, that is definitely a bug.
>>
>> Recent updates to the javadoc for Lookup (in JDK 8) emphasize this
>> correspondence principle strongly.  If it breaks, we want to know
>> about it.
>>
>> Thanks for the report and the double-check.
>>
>> — John
>
>



More information about the hotspot-runtime-dev mailing list