On 23/08/2021 07:46, Jaikiran Pai wrote:
:
So if any of the upcoming Java 18 EA builds introduce the "disallow"
by default, then if Ant has to test against those EA builds (not just
for SecurityManager but any other changes), then Ant project will have
to start setting the "java.security.manager" system property to
"allow". That's not going to be straightforward, since it would be
dealing with this in potentially multiple launch scripts or maybe even
dynamic launch commands issued through the code (I haven't checked
where/how many). I don't yet know if this property value can be
changed at runtime/dynamically. If that is allowed, it may make things
a bit easier since that would allow us to set that property value at
the same place where we set the custom security manager in the Ant
code, but I would still like to avoid it if possible.
So given all this, can the new API(s) design/implementation for
preventing System.exit(...) calls without a SecurityManager be
prioritized and perhaps be scheduled for release in Java 18 itself,
which is where the "disallow" will come in as default?
To summarize - Ant would need a way to intercept/prevent JVM exits via
System.exit(...) or Runtime.getRuntime().exit(...) calls *and* a way
to get hold of the exit code that was used to trigger such calls (Ant
had to wrap the SecurityException into a custom exception type just to
keep track of that exit code value).
Once the JDK is changed to disallow setting a SM dynamically then it
will require the command line option to keep existing code that calls
System.setSM working. This change should have little-to-no impact on
libraries as it would be rare for a library to set a SM. It will have
impact on applications and tools that do set it dynamically as they will
need the CLI option to allow a SM be set.
The System.exit use-case is well studied. It has come up several times
over the years in the context of tools that want to prevent accidental
calls to System.exit by plugins/other programs that are run "in
process". Your description of the fork mode where it runs the task "in
process" seems to match this. I assume one option is to just catch UOE
or not attempt to set a SM on >= 18, it just means that tools that do
call System.exit will cause ant to shutdown with maybe a shutdown hook
used to log a message.
It's too early to point to a specific API/proposal at this time. There
were early exploratory sketches a few years ago but they didn't go very
far. The main thing is that we don't want to introduce APIs for
intercepting specific operations in isolation, e.g. we don't want one
API to intercept System.exit and a completely different API for
intercepting attempts to make socket connections for example. So TBD,
and I'm sure there will be a lot of discussion on the mailing lists.
-Alan
