[
https://issues.apache.org/jira/browse/POOL-352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16652882#comment-16652882
]
Gary Gregory commented on POOL-352:
-----------------------------------
Patches welcome!
> CallStackUtils mishandles security manager check
> ------------------------------------------------
>
> Key: POOL-352
> URL: https://issues.apache.org/jira/browse/POOL-352
> Project: Commons Pool
> Issue Type: Bug
> Reporter: Volker Kleinschmidt
> Priority: Major
>
> 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().
> 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
(v7.6.3#76005)
