[
https://issues.apache.org/jira/browse/POOL-372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Phil Steitz updated POOL-372:
-----------------------------
Fix Version/s: 3.0
> 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
> Fix For: 3.0
>
>
> 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)
