There are problems with the agent approach, finalizer's must be
disabled, but there are other issues, such as replacement of
doPrivileged calls and the need to widen permission grants as everything
is on the stack.
I did consider a mode where there are no privileges unless a privileged
call had been made...
I have documented it here:
https://github.com/pfirmstone/HighPerformanceSecurity
--
Regards,
Peter
On 15/10/2024 11:20 pm, Robert Engels wrote:
Just read the JEP for this. Very poor decision in my part - maybe Java’s death
knell. Going to make IDEs with plugins huge security risks.
How hard is it to maintain 1000 one line pieces of code?
Someone commercial company is going to write an agent and essentially replicate
all of these calls.
Not sure what’s happening with the Java steering committee.
On Oct 15, 2024, at 8:04 AM, Chen Liang <li...@openjdk.org> wrote:
On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan <mul...@openjdk.org> wrote:
This is the implementation of JEP 486: Permanently Disable the Security
Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The
[CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main
changes in the JEP and also includes an apidiff of the specification changes.
NOTE: the majority (~95%) of the changes in this PR are test updates
(removal/modifications) and API specification changes, the latter mostly to
remove `@throws SecurityException`. The remaining changes are primarily the
removal of the `SecurityManager`, `Policy`, `AccessController` and other
Security Manager API implementations. There is very little new code.
The code changes can be broken down into roughly the following categories:
1. Degrading the behavior of Security Manager APIs to either throw Exceptions
by default or provide an execution environment that disallows access to all
resources by default.
2. Changing hundreds of methods and constructors to no longer throw a
`SecurityException` if a Security Manager was enabled. They will operate as
they did in JDK 23 with no Security Manager enabled.
3. Changing the `java` command to exit with a fatal error if a Security Manager
is enabled.
4. Removing the hotspot native code for the privileged stack walk and the
inherited access control context. The remaining hotspot code and tests related
to the Security Manager will be removed immediately after integration - see
[JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
5. Removing or modifying hundreds of tests. Many tests that tested Security
Manager behavior are no longer relevant and thus have been removed or modified.
There are a handful of Security Manager related tests that are failing and are
at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt`
and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or
separate bugs will be filed before integrating this PR.
Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager`
and `AccessController::doPrivileged` for now, as these methods have been
degraded to behave the same as they did in JDK 23 with no Security Manager
enabled. After we integrate this JEP, those calls will be removed in each area
(client-libs, core-libs, security, etc).
I don't expect each reviewer to review all the code changes in this JEP.
Rather, I advise that you only focus on the changes for the area (client-libs,
core-libs, net, security, etc) that you are most f...
@seanjmullan I think you can use many lines of command in one github comment,
like
-------------
PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2411850563
