[jboss-as7-dev] About the getSecurityManager() optimization

[Brian Stansberry]

On 3/4/13 9:40 AM, David M. Lloyd wrote:
> On 03/04/2013 09:35 AM, Anil Saldhana wrote:
>> The reason why we had package level securityactions/privileged blocks
>> was mainly to provision the permissions down to the package level (if
>> need be). Having singleton classes representing priv blocks may be ok
>> for AS core code. However, how do we prevent applications from using these
>> singleton priv blocks?
>
> No need to do so - the application still has to use doPrivileged from
> their own code base.  All we do is provide an object to give to it, to
> avoid redundant classes from being defined and object instances from
> being created.  IOW there's no security risk that didn't already exist.
>
> That said, this API is private (aka not supported by us for external
> use), so we're free to change it or remove it at any time if we need to.
>

BTW, there's some useful stuff in the old jboss-common-core for this 
area, particular for system properties and TCCL changes. The gist of it 
was the caller would request an instance of a utility class in a 
privileged block and the necessary permission checks would be performed 
during construction of the instance. The caller could then cache the 
utility object and reuse. This eliminates the redundant privileged 
blocks and package protected SecurityActions classes we have.

See for example org.jboss.util.loading.ContextClassLoader and 
ContextClassLoaderSwitcher. I found the latter most useful, since a 
typical TCCL manipulation involves 3 actions, a get, a set and another 
set to restore in a finally block.

The caller of course has to be careful not to let the cached security 
util instance leak.


-- 
Brian Stansberry
Principal Software Engineer
JBoss by Red Hat