Using lookups in place of reflection

[Andrew Dinn]

On 21/04/17 11:57, Alan Bateman wrote:
> The check in checkUnprivilegedlookupClass isn't new, I think it's a
> defense-in-depth check that goes back to JDK 7 to catch usages of full
> power lookups in fully privileged code. There was recent discussion on
> core-libs-dev about this, prompted by work that Paul Sandoz was doing to
> retrofit LockSupport and TLR to use privateLookupIn. My recollection is
> that he relaxed the check to allow the target class be Thread or a class
> in j.u.concurrent and the more general question on whether this check is
> needed was kicked down the road. I'm sure John Rose or Paul will jump in
> on this thread.

I'd be very pleased if they did :-)

> BTW: None of the modules defined to the boot loader open packages so I
> wouldn't expect too many people will run into this. You run into in the
> example because java.net.HttpURLConnection is in java.base and defined
> to the boot loader. I guess another possible scenario would be someone
> opening a package in a core module with `--add-opens` and the raiding
> party uses privateLookupIn.

Ah, well, actually ... my agent can run into this even when java.base
does not open a package. Byteman will open a package to its own private
module if it wants to access protected/private members of classes in
that otherwise unexported package.

Of course, it only does so to do the specific, targetted accesses
specified in rules provided by whoever installed the agent. It does not
make the handles (never mind the packages) available to non-agent code.

So, strictly ... I agree you are correct when you note that this is
something that will mostly only affect a small number of people -- it
only limits the options available to agent developers. Of course, that
doesn't mean it won't have a knock-on effect for users of those agent
(perhaps a rather larger commmunity :-).

regards,


Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander