module opens directive and Lookup::defineClass

[mandy.chung at oracle.com]

There is no conflict with JLS 7.2.2 as I can see.

Opens `some.package` to `some.other.module` means just one package.  
It's true that the open packages can be extended at runtime. For 
example, `some.other.module` can update this module to open the package 
to another module at runtime via `Module::addOpens` and even 
`Instrumentation::redefineModule` and `--add-opens` command-line option.

Module maintainers should always be very careful open any package and 
only open packages to trusted frameworks.

Mandy

On 1/30/23 11:32 AM, Kasper Nielsen wrote:
> Hi,
>
> I just saw the pull request for 8217920 (Lookup.defineClass injects a class
> that can access private members of any class in its own module.)
>
> The PR details how you can generate a class in a package that has been opened
> to you via a module declaration. This generated class can then create a new
> lookup object with full privileged access and pass it back to you. You can
> then use this lookup object to reflective access *any* class in the module,
> not only the packages that were opened to you.
>
> In practice, this now means that the opens package directive is a wildcard
> directive.
>
> module mymodule {   opens some.package to some.other.module; }
>
> means
>
> module mymodule {   opens *all-my-packages* to some.other.module; }
>
> Which conflicts with JLS 7.7.2. Exported and Opened Packages that says:
>
> The opens directive specifies the name of a package to be opened by the
> current module. For code in other modules, this grants access at run time,
> but not compile time, to the public and protected types in the package, and
> the public and protected members of those types. It also grants reflective
> access to all types in the package, and all their members, for code in other
> modules.
>
> I understand the need to be backward compatible. But I find this behavior
> of 'opens' surprising given that the directive takes a package name.
> Also, the paragraph does say anything about granting the right to define new
> classes in the package. It only talks about reflective access.
>
> For those that are curious. I've made a simple demo that exploits this here
> [1]. It takes a Lookup object and a class and will return a private lookup
> object to the specified class if there is at least one open clause from the
> module (of the specified class) to the caller. Irregardless if the specified
> class is in an open package.
>
> /Kasper
>
> [1] https://gist.github.com/kaspernielsen/e072a38654d63f2918540e24e9d0380e