<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi,<br>
<br>
I've read all the messages in this thread, and want to offer a
somewhat different perspective. I'm biased since I spend quite a
bit of my time working on Elasticsearch these days, which is an
application, so I'm technically "the user". We experimented with
and provided feedback on the FFM API several times over the years.
As part of that, we evaluated and have a positive view of the
restrictions on native access. <br>
<br>
Elasticsearch directly and indirectly leverages natives; directly
from JNA, and indirectly as we use Netty. Our plan and previous
experiments have been to replace our use of JNA with the FFM API.
Given our particular usage, we're not overly concerned with
performance (though our experiments showed that the FFM API way
outperforms JNA), but rather the benefits of the native access
restrictions. The core of the Elasticsearch platform is
modularized, and as such we'll limit native access to just the
modules that need it. Additionally, we'll use
`ModuleLayer.Controller.enableNativeAccess` to grant access to JNI
from Netty, as we load Netty in a child layer of the boot layer.<br>
<br>
FWIW, I like the alignment JNI and the FFM API, in this respect.
Both old and new are treated in a similar way.<br>
<br>
Again, I'm "the user" and Elasticsearch already starts from a
script, so adding `--enable-native-access=M` is not a big deal.
What is important for us is that the warnings are suppressible -
which they are in this particular case. In fact, all warnings
should be suppressible by the user, which is not currently the
case, but that is orthogonal.<br>
<br>
I want to highlight one specific use case. We use JNA during the
startup of the server to do configuration and setup-like things.
The most significant being to install system call filters, that
among other things, block process execution, e.g. through seccomp
on Linux. Elasticsearch currently runs with a restrictive security
manager installed, and the use of system call filtering is one
particular mitigation (along with static analysis and byte code
instrumentation), that will be required once the security manager
is removed. I don't think this use case identifies a fundamental
design issue with this JEP, but seems a little counterintuitive -
the enablement of inherently dangerous native access to enable
process-level restrictions. However, the future actual
restrictions and the auditability of native usage are very much
welcome.<br>
<br>
-Chris.<br>
</p>
<div class="moz-cite-prefix">On 04/09/2023 07:49, Alan Bateman
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:cca8d789-f756-5d2a-e789-f942db8898f5@oracle.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
On 01/09/2023 22:16, Attila Kelemen wrote:<br>
<blockquote type="cite"
cite="mid:CAKDaPBfHdPkvJpCA_Zs=xmDsNKhzkdULOvZTV1S5YEtV6_Q+zQ@mail.gmail.com">
:<br>
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div>When I wrote "stop using the module system" I'm
obviously talking about the application itself being
modular. I would have expected that you also believe that
it would be better, if applications were modular. Given
that I assumed from what you wrote that you regret the
fact that modules were not added on day 1 (in which case
there would only be modular apps most likely). Yet, this
JEP just motivates people away from modules.<br>
</div>
</div>
</div>
</blockquote>
<br>
I don't think this is the case. Instead I think there is a lot of
potential for a much better story. Modules lend themselves to
doing a lot more at build time and setting things up for
simple/fast checks at startup (think post resolution checks).
It's not hard to think about fail fast if a module requires the
"restricted methods or native code" capability that has not been
granted. Combing a set of modules at link time also has a
potentially interesting story when using jlink to create an
application that has an initial/main module. In that case, you can
think about checking capabilities (or whatever term is introduced)
at build/link time.<br>
<br>
-Alan<br>
</blockquote>
</body>
</html>