Should setAccessible be part of Java or not? (was Re: It's not too late for access control)

[Andrew Dinn]

On 14/07/16 10:56, Alan Bateman wrote:
> This project (and JSR) is not proposing to remove setAccessible as that
> would break many things. The comment that Andrew Dinn picked up started
> with "In the very long term ..." and is a throw away comment on where
> the platform needs to go long term. In general then we need to find
> better solutions for things that setAccessible is used for today. That
> could take years and many major releases. It's a bit like the Unsafe
> issue in that regard.

I am glad to hear that

 "In the very long term then setAccessible needs to go away of course"

is an opinion not a decision.

> Confusion aside, we have taken a first baby step towards degrading
> setAccessible so that it can't be used to break into non-exported
> packages. There was discussion about this on the EG mailing list last
> year, much discussion on it here too.

There has indeed also been discussion recently about retaining the
ability to break into non-exported packages. I think it needs to continue.

> Agents (Andrew Dinn's main interest I think) have the power to change
> bytecode and extend modules at runtime to break encapsulation. I don't
> think there is anything to be overly concerned here.

I am doubtful that my interests are the only ones at stake here nor
indeed that the problem relates solely to agents. I suspect solving the
related problems faced by middleware will also have some dependence on
the ability to use setEnabled. I hope the current discussion will
clarify whether the need for this API extends to those cases. However,
let us just consider agents for the present.

Changing bytecode is a powerful capability but it is limited by the
constraints imposed by the verifier. In particular, that means a
dynamically loaded agent is only capable of providing access to
immediate private members from bytecode directly injected into the
owning class.

That provides highly limited access. For example, accessing through an
object network with disparate link types is not possible in this way
(i.e. accessing this.bar.baz where baz and bar are both private fields
of different types to this). Of course, reflection combined with
setEnabled does indeed permit such accesses.

Redefining modules via the Instrumentation class looks like it may well
provide a means to access module non-public data/behaviours in a
restricted fashion from an agent (I am close to having a working version
of Byteman using this new capability). However, it only does so thanks
to the continued presence of the setEnabled API. So, if this API is to
be removed -- whether in the sort or long term -- then this will be
problematic for my agent and, no doubt, for others. I believe that at
the very least requires wider consultation.

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