1

Is it acceptable to globally and finally store the check for a security manager?

Given the following line of code:

public static final boolean SEC_ON = (System.getSecurityManager() != null);

Would it be acceptable to place this in a library and reuse the result throughout the lifetime of the JVM?

Why? or Why not?

[update] Similar code exists in the reference implementation of the Java EE - JSP specification. Any app server/servlet container which uses it will not support dynamic configuration of a SecurityManager.

Dog
  • 7,707
  • 8
  • 40
  • 74
Ray
  • 1,324
  • 10
  • 18
  • 1
    What are you going to use SEC_ON for? In your application, can the Security Manager change during the lifetime of the JVM? If it can change, do you need to know of this change? – Marcelo Aug 19 '13 at 20:28
  • Thank you for your response. The code is not mine. It's found in the reference implementation of a well established Java EE specification. The code has existed for at least half a dozen years if not more like 10. – Ray Aug 20 '13 at 03:10
  • Which implementation? Is it really a secret? – user207421 Aug 20 '13 at 05:07
  • JSP (javax.servlet.jsp) The impl is Jasper. – Ray Aug 20 '13 at 13:53
  • That would be a huge security loophole: one could arbitrarily change that variable through reflection. `final` doesn't help. – Marko Topolnik Aug 21 '13 at 10:45
  • Thanks for your comment Marko, and you are right that final is not a protection. However, I do not believe in this case that this was done for protection of any kind. Rather I believe it was a small optimization to reduce startup initialization cost (with respect to Java Security objects which need to be created for jacc). But what it DOES mean is that if the check is made, and later an SecMan is installed, these objects, and JSP RI will misbehave. – Ray Aug 21 '13 at 14:42

3 Answers3

1

No. A security manager can be installed at any time if not present initially.

user207421
  • 305,947
  • 44
  • 307
  • 483
  • Thank you for your response. I agree with you. However,my intent is to see how much feedback I get on the topic because I'm trying to build a case to argue changing this in a Java EE reference implementation. The likelyhood of getting feedback by filling a bug report is very low since the maintainers don't seem intent to communicate about any issues. – Ray Aug 20 '13 at 03:11
1

Since the security manager can change at any time during the lifetime of the JVM, this is not a good practice. If they need a convenience shortcut, they should use a method such as:

public static boolean isSecurityOn() {
    return (System.getSecurityManager() != null);
}
Marcelo
  • 11,218
  • 1
  • 37
  • 51
0

After petitioning the Java EE user group on the subject (https://java.net/projects/javaee-spec/lists/users/archive/2013-08/message/8), it appears their stance is to not make any such determination about whether it's ok to do this or not.

So, sadly while we may wish the answer to be "you should not do that", the reality is that you cannot rely on that assumption, because someone is and will probably continue to do it.

Ray
  • 1,324
  • 10
  • 18