Minor thoughts (Re: [External] : Re: JEP draft: Prepare to Restrict The Use of JNI

[Glavo]

Fix the problem in the previous mail:


> The main module is not the user. The user is the person who develops,
>> maintains, or otherwise "owns" the application. The main module is part
>> of the application. The point of the JEP is to let the user, outside the
>> application, acknowledge the risk arising from use of JNI inside the
>> application (whether in the main module or six levels down).
>>
>
> My question is why should we distinguish between the author of the main
> module and the packager of the program?
> Is such an identity completely independent of developers really meaningful?
>

What I should say here is: Why treat the main module as a normal part of
the program?
I think that most of the time, the main module author is what you would
call the "user".

I still have something to say, but I spend too much time on the mailing
list, so maybe I'll sort out what I want to say tomorrow.

Glavo

On Mon, Sep 4, 2023 at 9:23 AM Glavo <zjx001202 at gmail.com> wrote:

> No, there’s some misunderstanding here. The “end user” from the
>> perspective of the JDK is the application author/maintainer. It is not the
>> end user of the Java *application*.
>>
>
> Of course I know this, because you have said it many times.
> When I said that I hope to declare relevant information in the module
> information of the main module, Alex replied like this:
>
> The main module is not the user. The user is the person who develops,
>> maintains, or otherwise "owns" the application. The main module is part
>> of the application. The point of the JEP is to let the user, outside the
>> application, acknowledge the risk arising from use of JNI inside the
>> application (whether in the main module or six levels down).
>>
>
> My question is why should we distinguish between the author of the main
> module and the packager of the program?
> Is such an identity completely independent of developers really meaningful?
>
> If the other methods were restricted but not JNI, those libraries will use
>> JNI for that purpose.
>>
>
> This reason would lead me to believe it if the same restrictions were not
> imposed on Panama.
> I support more restrictions on JNI to move users to Panama, but I would
> like Panama to be available without JVM options.
>
> I'm not saying there should be no restrictions at all. For features like
> this that is really needed by people, I wish it could be managed more
> finely.
> This is what I want (3rd repetition):
>
> 1. Allows a module to declare that it wants native access:
>>
>> ```java
>>
>> module org.glavo.mylib {
>>     requires native; // Check for permissions when loading
>>
>>     // or
>>     requires static native;  // Check for permission when calling a
>> restricted method
>>
>> }
>>
>> 2. Allows a module with native access enabled to grant permissions to
>> other modules:
>>
>> ```java
>>
>> module org.glavo.myapp {
>>     requires native;
>>     requires org.glavo.mylib;
>>
>>     opens native to org.glavo.mylib;
>>
>> }
>>
>>
>> 3. If the main module requires native access, it is allowed without the
>> --enable-native-access.
>>
>> 4. Allows users to declare restricted methods.
>>     This will prevent code from masking its true intent through low-level
>> libraries like JNA/JNR.
>>
>>
> I think future I/O should be limited in a similar way, since users can use
> it to break integrity as well.
> For example, using /proc/pid/mem can bypass the restriction and write
> directly to memory.
>
> I know you have some descriptions in the "future work", but you are now
> preparing to modify the default behavior of the program.
> Even just printing a warning is not harmless, it is urging the user to go
> somewhere.
> So please don't let them be "future work", they should be "dependencies".
>
> -cp is a flag (even with ‘lib/*’), and the same work done to automate the
>> classpath could be applied to this flag as well.
>>
>
> In theory, build tools could do this, but they haven't done so yet. It
> sounds like you want the Java community to do this?
> Then I must remind you that if it is not the OpenJDK team but the Java
> community that does this, then the future development direction will not be
> in your control.
> As I said in another email, this will cause irreparable damage to the
> integrity.
>
> I like --add-opens the way it is now because it gives everyone enough
> negative feedback to keep people away from it.
> But if the community does this, the vigilance effect of --add-opens will
> be greatly reduced, and more people may no longer think that breaking
> module encapsulation is a super power.
> Therefore, I hope that FFI, I/O, these superpowers that people really
> need, should not be treated in the same way.
>
> Glavo
>
>
> On Sun, Sep 3, 2023 at 1:48 AM Ron Pressler <ron.pressler at oracle.com>
> wrote:
>
>>
>>
>> > On 2 Sep 2023, at 14:51, Michał Kłeczek <michal at kleczek.org> wrote:
>> >
>> >
>> > 1. I was talking about social issues - seem to me they would be the
>> same if you tried to enforce SecurityManager
>>
>> The social aspect is certainly one of the most interesting and
>> challenging parts, and the main reason why we’re moving so cautiously.
>>
>> > 2. I am not convinced that it really works as well as advertised by
>> OpenJDK team. For example: you ignored my question about dynamically loaded
>> modules - how are they handled by these command line flags?
>>
>> That's in the JEP.
>>
>> — Ron
>>
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20230904/ffc49406/attachment-0001.htm>