[ 
https://issues.apache.org/jira/browse/POOL-352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Gary Gregory closed POOL-352.
-----------------------------
       Resolution: Fixed
    Fix Version/s: 2.7.0

Fixes (a) but makes no attempt at addressing (b), for which [POOL-372] exists.

> CallStackUtils mishandles security manager check part 1
> -------------------------------------------------------
>
>                 Key: POOL-352
>                 URL: https://issues.apache.org/jira/browse/POOL-352
>             Project: Commons Pool
>          Issue Type: Bug
>            Reporter: Volker Kleinschmidt
>            Priority: Major
>             Fix For: 2.7.0
>
>
> This ticket is for (a).
> 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
(v7.6.14#76016)

Reply via email to