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

[David M. Lloyd]

On 03/04/2013 10:42 AM, Brian Stansberry wrote:
> 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.

Yeah that's a good idea (though the switcher instance still needs to 
instantiate action instances for its internal doPrivileged calls).  But 
this kind of thinking - caching action instances - could help with GC 
pressure (especially on a per-request basis).

-- 
- DML