[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jakarta-commons-dev
Subject:    [jira] [Commented] (POOL-372) CallStackUtils mishandles security manager check part 2
From:       "Niall Pemberton (Jira)" <jira () apache ! org>
Date:       2022-12-31 0:55:29
Message-ID: JIRA.13246939.1564018301000.245225.1672448580034 () Atlassian ! JIRA
[Download RAW message or body]


    [ 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)


[prev in list] [next in list] [prev in thread] [next in thread]