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

[David M. Lloyd]

We have, in our core code and frameworks, a few chunks of code like this:

   if (getSecurityManager() == null) {
      doSomePrivilegedThing();
   } else {
      AccessController.doPrivileged(new PrivilegedThingAction());
   }

The idea is that doPrivileged and the action GC load is a cost we should 
not pay if there's no security manager.

There is a potential problem here though.  It is possible to install a 
security manager after the server is started.  While this may sound like 
an odd thing to do, we know that at least one third-party library does 
in fact install a security manager if you don't prevent it from doing 
so.  Furthermore, as we're required to support running under a security 
manager, we were talking about allowing the subsystem to install a 
security manager during extension init instead of requiring it to be 
sent in to the command at boot.

The problem is that if you set a security manager during the window 
between when the presence of a security manager is checked for, and when 
the privileged action runs, you run the risk of getting a random 
SecurityException.  We'll call this problem "the SM race".

It seems to me that we have a few options for supporting running under a 
security manager:

1) Require it to be specified at boot (pass -secmgr to JBoss Modules in 
the start script)
2) Let it be set by a security manager subsystem
3) Just run with a security manager at all times

Only #1 would allow the above optimization to work, and that's only if 
nobody else sets a security manager in the meantime.

Given that fact, coupled with the observation that running under a 
security manager does not appear to significantly impact server boot 
time, I'm wondering if we should get rid of this optimization wherever 
it appears and just always use doPrivileged.

Maybe once we see what kind of time impact -secmgr has on the test 
suite, we'll know whether this is a reasonable course of action (I would 
expect the performance impact to be somewhere between running with and 
without a security manager for the non-SM case, and of course no impact 
for the SM case).
-- 
- DML