[
https://issues.apache.org/jira/browse/POOL-372?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17653233#comment-17653233
]
Niall Pemberton commented on POOL-372:
--------------------------------------
The Security Manager was deprecated in *Java 17,* so at some point this feature
will need to be removed:
* [https://openjdk.org/jeps/411]
>From what I understand, this feature produces a limited stack trace (no method
>names or line numbers) in a more efficient manner than the Throwable
>implementation for debugging purposes.
Perhaps an alternative would be to replace the whole stack trace debugging
feature with *Flight Recorder* events introduced in {*}Java 11{*}?
* https://openjdk.org/jeps/328
> CallStackUtils mishandles security manager check part 2
> -------------------------------------------------------
>
> Key: POOL-372
> URL: https://issues.apache.org/jira/browse/POOL-372
> Project: Commons Pool
> Issue Type: Bug
> Reporter: Volker Kleinschmidt
> Priority: Major
>
> This ticket is for (b).
> CallStackUtils determines at initialization time whether it is allowed to
> create a security manager, then sticks that info into a static variable and
> never checks it again, relying on this check to later try to create a
> SecurityManager for a SecurityManagerCallStack. This is doubly wrong:
> a) If the code is running in a privileged context at init time, it determines
> that it can create a security manager, and then later naively assumes that
> henceforth all code is privileged and also can create a security manager. Of
> course this is not true, otherwise one would not need a security manager in
> the first place! This info can never be kept in a static variable, it's
> extremely context-dependent. So this leads to AccessControlException from
> invoking newCallStack() if abandoned object logging is enabled.
> b) The permission to create a security manager must never be granted to any
> code, unless that code has AllPermission in the first place, i.e. is already
> fully privileged. This is because this permission allows circumventing the
> security manager completely (simply create one that lets all checks pass).
> Therefore even just checking whether you're allowed to create a secmgr is
> naive - if a secmgr is installed at all you should assume that you're NOT
> privileged enough to do this, simply because for sure some code that calls
> your code will not be privileged enough.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
