JEP 411: Deprecate the Security Manager for Removal

[Vasiliy Yashkov]

Hi!

In JDK 17 the Security Manager has been marked for removal. It is planned to be removed permanently in a future version https://openjdk.java.net/jeps/411. 

The security manager is also used in Jaybird in monitoring operator execution and setting network timeout and in FBJava plugin.

What do you think about removing it? Is there any point in replacing it with something else?

Vasiliy

[Mark Rotteveel]

Currently JDBC requires SecurityManager checks in some places, so until
SecurityManager is really removed, or when JDBC requirements change,
there is nothing that needs to change now (though I will consider simply
removing some of the security manager checks in Jaybird 5, as to be
frank, the primary reason JDBC has it is because of applets...).

As far as I understand from the JEP, they will first degrade the API
(e.g. by never giving access to the security manager, or always allowing
operations) before SecurityManager is really removed.

I am not planning on using something else, so when SecurityManager is
really removed, usage of SecurityManager will simply be removed, without
a replacement.

Above remarks only applies to Jaybird itself, I can't speak for the
needs and requirements of FB/Java.

Mark
--
Mark Rotteveel

[Mark Rotteveel]

On 26/11/2021 18:05, Mark Rotteveel wrote:
> On 25-11-2021 15:53, Vasiliy Yashkov wrote:
>> Hi!
>>
>> In JDK 17 the Security Manager has been marked for removal. It is
>> planned to be removed permanently in a future version https://
>> openjdk.java.net/jeps/411.
>> The security manager is also used in Jaybird in monitoring operator
>> execution and setting network timeout and in FBJava plugin.
>>
>> What do you think about removing it? Is there any point in replacing
>> it with something else?
>
> Currently JDBC requires SecurityManager checks in some places, so until
> SecurityManager is really removed, or when JDBC requirements change,
> there is nothing that needs to change now (though I will consider simply
> removing some of the security manager checks in Jaybird 5, as to be
> frank, the primary reason JDBC has it is because of applets...).
>
> As far as I understand from the JEP, they will first degrade the API
> (e.g. by never giving access to the security manager, or always allowing
> operations) before SecurityManager is really removed.
>
> I am not planning on using something else, so when SecurityManager is
> really removed, usage of SecurityManager will simply be removed, without
> a replacement.

With Java 24, https://openjdk.org/jeps/486 will permanently disable the
security manager, and JDBC 4.4 (see [1]) scheduled for Java 24 will
remove the requirement to for SQLPermission checks (this is the only
change in JDBC 4.4).

For now, the APIs remain in place, you'll just never be able to get a
SecurityManager to actually check for permissions.

I'm currently considering removing the SQLPermission checks preemptively
in Jaybird 6, though on the other hand, for now the code will continue
to work (but from Java 24 on there simply won't ever be an actual
SecurityManager instance to perform such a check). I guess in practice
no one is actually using a SecurityManager anyway, so I don't expect
problems from removing it prematurely.

Code using AccessController.doPrivileged will remain in place a little
bit longer until that API really is removed.

Does anyone else have an opinion on this (removing SQLPermission checks)?

Mark

[1]:
https://jcp.org/aboutJava/communityprocess/maintenance/jsr221/index4.html

--
Mark Rotteveel

[Mark Rotteveel]

On 13/12/2024 14:56, 'Mark Rotteveel' via firebird-java wrote:
> With Java 24, https://openjdk.org/jeps/486 will permanently disable the
> security manager, and JDBC 4.4 (see [1]) scheduled for Java 24 will
> remove the requirement to for SQLPermission checks (this is the only
> change in JDBC 4.4).
>
> For now, the APIs remain in place, you'll just never be able to get a
> SecurityManager to actually check for permissions.
>
> I'm currently considering removing the SQLPermission checks preemptively
> in Jaybird 6, though on the other hand, for now the code will continue
> to work (but from Java 24 on there simply won't ever be an actual
> SecurityManager instance to perform such a check). I guess in practice
> no one is actually using a SecurityManager anyway, so I don't expect
> problems from removing it prematurely.
>
> Code using AccessController.doPrivileged will remain in place a little
> bit longer until that API really is removed.
>
> Does anyone else have an opinion on this (removing SQLPermission checks)?
>
> Mark
>
>  [1]: https://jcp.org/aboutJava/communityprocess/maintenance/jsr221/
> index4.html

I've changed my mind, and I'll leave the permission checks in place for
now, and only remove them - possibly in a point release - once a Java
version is released (or, about to be released) that actually removes
classes or other API necessary for these checks. That is not expected
until after Java 26 (2026).

That way, Jaybird will remain compliant with JDBC 4.3 for the time
being, while also being compliant with Java 4.4 (as those checks, even
when they exist in code, will never be performed in Java 24 or higher,
so the effective result is the same).

Mark
--
Mark Rotteveel