What's the performance penalty, if any, of using a SecurityManager

Question

Is there a performance penalty when using a SecurityManager?

I need the following:

public class ExitHelper {

    public ExitHelper() {

        System.setSecurityManager(new ExitMonitorSecurityManager());

    }

    private static class ExitMonitorSecurityManager extends SecurityManager {

        @Override
        public void checkPermission(Permission perm) {}

        @Override
        public void checkPermission(Permission perm, Object context) {}

        @Override
        public void checkExit( final int status ) {
            // this is the part I need and I don't care much about the performance issue of this method
        }
}

Will this have a huge impact on my program?

The program does open a lot of files, for example. And if I enable the SecurityManager and put some logging in there, I can that these methods are called a lot. Really a lot. So much that normal logging is lost amongst logging from these two methods. So it seems putting a SecurityManager into place means that lots and lots of calls are made. Would it be any slower than the default SecurityManager? (is there any by default?)

How does this work? Which part of the program will be checked for permissions and how often? I'm concerned by the two checkPermission(...) methods.

Answer 1

There is a performance penalty, but it is likely to be small because:

• It only applies when you attempt some form of activity that requires a permission check.
• Most operations that require permission checks are expensive operations (IO, network access etc.), so it is likely that the overhead of security checks is going to be a pretty low percentage of total runtime.
• The check itself can be made very cheaply

In particular, note that the calling code for security checks is typically very lightweight in the Java library code, i.e. something like this:

 SecurityManager security = System.getSecurityManager();
 if (security != null) {
     security.checkXXX(argument,  . . . );
 }

If your security manager code itself is equally lightweight, then the runtime cost of the security check should be negligible. I would avoid putting any logging code in the SecurityManager itself however - this would be costly and probably belongs at a higher level in your application code.

If you want to absolutely minimise the overhead of the security manager for permissions that you don't care about, then you should override the specific checkXXX methods that you don't need with something like:

@Override 
public void checkRead(String file) {
  // empty method as we are happy to allow all file reads
}

Ultimately you'll have to benchmark for your particular situation, but the "gut feel" answer would be that you shouldn't really be worrying about it.

Answer 2

yes there is a performance penalty. if you are concerned about it, your only recourse is to measure it and see if the penalty is too high.

one potential solution for your specific use case is if you can narrow the scope of when it's needed. you clearly want to stop some code which you don't control from exiting the application. if you know when that code could be invoked, then you can just set the security manager during that call (note, you need to be aware of threading affects here since the security manager setting is global), e.g.:

System.setSecurityManager(new ExitMonitorSecurityManager());
try {
  // ... do protected op here ...
} finally {
  System.setSecurityManager(null);
}

UPDATE:

to clarify to those who may be coming to this answer later, this answer is not designed for dealing with potentially malicious code. In that situation, an appropriately configured SecurityManager should be in place at all times. This answer assumes that the OP is trying to deal with a poorly written third-party library which makes an unfortunate call to System.exit() at some, well defined point in time.