An Oracle blog about Java Technology

  • Sun
    February 8, 2006

Running applications on GlassFish and the security manager

Guest Author


So why does this deploy and run without errors on some other Java EE Servers, but glassfish complains? Answer: Glassfish is much more security conscious.

Ken Paulsen has a really good blog about his experience getting jive to run on GlassFish. Right away he gets an exception because the security manager is restricting permissions on the application. Above is a quote from his blog where he details how to configure the GlassFish security manager to relax permissions or simply turn it off. Turns out this isn't the first time users have seen this issue. Vince ran into the same thing when he tried to get Equinox running on GlassFish.

Last month we featured a blog by Felipe titled "Do you want security in your App Server?" as he found most servers run with the security manager disabled by default. I have to wonder if application writers really prefer security managers disabled or if they simply don't realize that they are developing to that environment.

Security, Java EE,

Join the discussion

Comments ( 4 )
  • D. J. Hagberg Thursday, February 9, 2006
    I understand the initial concept that having a SecurityManager active in the AppServer could, potentially, improve security. The only value I can see is if code is dynamically inserted into the AppServer post-deployment, via RMI or Jini remote class loading facilities.
    But in practice, all the code running on the AppServer in production is trusted, either having passed a rigorous QA cycle, being vetted 3rd-party/open-source components, or code written by the developers themselves.
    In that case, what does the SecurityManager buy you other than reduced performance?
  • Eduardo Pelegri-Llopart Friday, February 10, 2006
    Hi, D.J. thanks for the comment...
    "Trusting Code" is risk analysis assessment. In general, the larger the code base, the more important the task, and the costlier the recovery, the less one trusts code. This is true up and down the stack: Java was very succesful in capturing mindshare from C++ because it let you trust that many bad things could not happen, but when you go into highly critical code (like a medical monitoring system) you need more.
    Back to server-side apps. So how much you are willing to trust your code depends. In practice, when you build something from a bunch of JARs, assumptions of what is happening are hard to track, and it is not uncommon to find a "oh, I was not expecting this". But, if you are running a personal Web App on your laptop, that may be OK.
    - eduard/o
  • guest Friday, February 10, 2006
    Eduardo, I partially agree with you. But I think D. J. has a point. If you are saying that the application code is less trustworthy than the app server code itself, then the app server code should guarantee that it does not do anything malicious, which is rather hard. [This is because the default server.policy grants all the permissions to the app server code, not so for application code].
    Maybe that's why the platform does not have a "default" server.policy because we don't know what the default should be.
  • Ron Monzillo Friday, February 10, 2006
    I am not yet up to blogging speed, so we'll see what happens here.
    The security manager is the means by which the Java runtime differentiates separate contexts of privilege above what would otherwise typically be a single process context. Below Java and in the eyes of the underling operating system, everything, the appserver and the various apps deployed or contained within the appserver appear as one - equally able (in the absence of a security manager) to avail themselves of whatever os protected facilities have been made available to the appserver process.
    Perhaps an oversimplification, but I generally view the appserver code as having the privileges of the os identity under which it is executing and expect the security manager to enforce code-based policy to reduce the privileges afforded to apps running within the appserver process.
    For this model to work effectively there needs to be some refinement in the default privileges afforded apps, and there is also an opportunity for better IDE and deployment support for granting apps privileges.
    As developers turn off the security manager, I suspect they are creating a downstream demand for tools or frameworks that can take their apps and make them run in the presence of a security manager.
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha