ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jaikiran Pai <jaiki...@apache.org>
Subject Re: Impact of Java SecurityManager being deprecated for removal post Java 17
Date Tue, 24 Aug 2021 10:40:22 GMT

On 23/08/21 9:17 pm, Stefan Bodewig wrote:
> On 2021-08-23, Jaikiran Pai wrote:
>
>> On 19/08/21 3:23 pm, Stefan Bodewig wrote:
>>> On 2021-08-19, Jaikiran Pai wrote:
>>>> Hello Stefan,
>>>> On 19/08/21 1:15 pm, Stefan Bodewig wrote:
>>>>> At a cursory glance I only see JUnitTask and ExecuteJava deal with the
>>>>> SecurityManager if permissions have been defined. Where else do we use
>>>>> one?
>>>>   From what I see in the Java task code[1], the "execute()" method of
>>>> that task calls, "checkConfiguration()"[2] method, which in a
>>>> non-forked mode, creates a Permissions instance if no explicit
>>>> permissions has been configured[3].
>>> I only searched for SecurityManager :-) Thanks.
>>> So we are using Ant's permissions system internally to preven
>>> System.exit, I see. This is the stuff we will need to replace with
>>> whatever is going to be the new API that prevents System.exit. Let's
>>> hope all this is not going to become an ugly hack.
>> Work has already started to "disallow" SecurityManager as early as
>> some upcoming JDK 18 EA release[1]. What that means is any calls to
>> System.setSecurityManager(...) would start throwing exceptions. I
>> haven't seen much discussion around any proposed API for the
>> System.exit(...) usecase. So I decided to explain Ant's use case and
>> request for the new API to be included in Java 18
>> hopefully. Discussion is here[2].
> Thanks. I'm not sure I understand Alan's answer, but if I do then it
> might happen that setSecurityManager throws exceptions before a
> different API is in place - and the only thing we can do is to tell our
> users to fork new VMs rather then run in process.

Yes, that's correct. There's no specific timeline specified for the new 
APIs, so those may or may not come within Java 18 GA time frame. So we 
have to wait and watch if this is going to impact just Java 18 early 
access releases or the final GA release too.


> This is not exactly the user experience I'd be hoping for, but so be it.

Agreed.

At this point, it's clear that, for us to be able to start consuming 
Java 18 early access releases in the coming weeks, we need to start 
passing around the "allow" value for the "java.security.manager" system 
property. Otherwise, we won't be able to test any of the other 
non-security manager related stuff that comes in, in these releases, 
because the bootstrapping of the task itself will start failing. I'll 
start taking a look at how involved this change is going to be.

-Jaikiran



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message