On 10/11/2010 21:15, Christopher Schultz wrote: > I'm looking for references that explain the interaction between the > SecurityManager itself, the policy, signed code, and the use of > AccessController/PrivilegedAction. > > Online resources and articles as well as dead trees would be fine. My > Google-fu just isn't turning up anything relevant. I get either horribly > technical specifications of things or trifles that just say "run under a > SecurityManager and everything will be secure!". > > Any help would be greatly appreciated.
I don't recall ever finding anything that useful. What I can do is condense my limited knowledge into a few lines that may help. For code to perform some actions (e.g. reading a file, exiting the JVM etc) it needs the associated permission when running under a security manager. The policy file handles mapping code to permissions. When code tries to perform a protected function then: - if no privileged block is present in the call stack then every class in the call stack must have the necessary permission - if a privileged block is present in the call stack then every class in the call stack from the class performing the action to the privileged block must have the necessary permission To take a specific example, consider the PersistentManager. It needs to read/write sessions from the file system, create objects, manipulate class loaders and a bunch of other stuff that requires permissions. Session loading/unloading can be triggered by a web application so it is possible for web app code to be in the call stack for a call to load(). Web apps have minimal permissions that do not include the permissions needed by the load() method. The PersistentManager class does have the necessary permissions. The load() method uses a privileged block so web apps can call the load() method without having the necessary permissions. To be secure the load() method has to make sure web apps can't trick it into doing something it shouldn't. Does that help? Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
