Hi Glenn, here is a couple of questions regarding your SecurityManager XML works:
(1) All permissions seems to be stored in class SecurityPolicyBase. The Map used to store permission is static, meaning all permissions will be stored in (why all? doing permissions.implies will browse every permissions instead of application-scope permission). This can be very slow. (2) Child scope will always have parent scope permissions. It there a reason? Can it be optional? (3) I didn't see any 'doPrivilege', 'Subject.doAsPrivilege' etc. in your code. I think we need to think about a notion of Tomcat Principal/Subject to only allow Tomcat doing those kind of operations (adding/removing permissions). This is usefull not only for your stuff, but for all security related call. (4) There is a class called sun.security.provider.PolicyFile where the "unmarshalling' of policy statement are made. Your XML Policy file do not define any Policy.implies method. meaning if XMLPolicy.implies is invoked, the call will be delegated to PolicyFile.implies, who doesn't know anything about the permission. This method will return false for every policy.xml permission sinde they are created outside the defaut Policy scope. If a Servlet try accessing a file that is not granted in the policy.xml file, right now, the permission will be allowed since the AccesController will call the Policy.implies......IMBW... (5) I did not see any statement about replacing the policy.provider=sun.security.provider.PolicyFile (using the -Djavax.security.jacc.policy.provider= ) ? (6) Your code define the policy configuration parts (permissions creation). What about the policy decision part? Which classes will enforce the permission created? The WebappClassLoader/ServletPolicyBase have a getPermissions() method, but I was unable to make the link between this method and the SecurityManager...Here is probably my inexperience with Tomcat..... (7) The security defined in the Deployment Descriptor may contredict the security defined in the policy.xml file. Which one will be applied? Ex: Access to folder X is denied by the policy.xml file, but granted to principal A in the deployment descriptor. (8) XMLPolicy define a method getPermission(CodeBase)....its parent define also a getPermission(ProtectionDomain). I recommend you overload that method (get the Codebase from the ProtectionDomain) and call your own getPermissions(Codebase). Just in case somebody like me call the getPermission(ProtectionDomain) ;-) (9) SecurityPolicyBase.clonePermissions() method: is there a reason why you cloning PermissionCollection? PermissionCollection are not thread safe, but Permission are immutable...its that the reason? Pretty interesting. I'm sure some JSR 115 concept can apply here. I would recommend we follow something similar, abstracting the Policy provider hooks in Tomcat to work not only with your XMLPolicy, but with every instance of a Policy class. This way I can easily replace your XMLProvider by a MyOwnProvider, 115Provider, etc. This way we can keep the -security option when starting Tomcat and by adding the -Djavax.security.jacc.policy.provider=org.apache.catalina.policy.XMLPolicy instead (you have something similar, but can I use it with my own Policy provider?). Just recommending :-)... -- Jeanfrancois -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
