System.exit(...) without SecurityManager - implications for Apache Ant project

[Alan Bateman]

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