Jean-Francois Arcand wrote: > Hi, > > I've re-factored Catalina.java and CatalinaService.java and merge the > security code into a single class: o.a.c.security.SecurityConfig. This > class will manage all the package access/definition security properties. >
Works for me! You might consider moving o.a.c.startup.SecurityClassLoad.java into o.a.c.security also since it is directly related to use of the SecurityManager. Is this change just in Tomcat 5? > Actually, the list of package access/definition are harcoded in that > class. I would like to propose we move this package list into a > Tomcat.security file following the J2SE format (see below). This way if > people needs accesses to a package, they will have the opportunity to do > it with having to recompile Catalina. > If someone needs access to a restricted package they can grant the appropriate RuntimePermission in their catalina.policy. What packages need restrictions rarely change. Moving the list of packages into a Global variable would make it easier to change these the rare times we need to. But I am -1 for adding a new config file just for this. If somone has their own packages which they feel need restrictions they can always update their own $JAVA_HOME/jre/lib/security/java.security file. > Righ now, some Watchdog tests are failling because they need accesses to > o.a.t.util, and yesterday, we have started protecting this package. > Either grant the appropriate permissions where needed in catalina.policy or wrap more code with doPrivileged() in catalina methods which need it. There are classes or sub packages in org.apache.tomcat.* which need to be restricted. But are the classes which are causing the failure ones which are sensitive from a security standpoint. If not, perhaps those classes should be moved into a different package which is not restricted. If this isn't workable then either grant the appropriate permissions where needed in catalina.policy or wrap more code with doPrivileged() in catalina methods which need it. SecurityManager related changes and subsequent testing with the default policy file and a very strict policy file can be a very painstaking process. I am happy to more developers getting involved in this area of Tomcat. :-) Regards, Glenn ---------------------------------------------------------------------- Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder | MOREnet System Programming | * if iz ina coment. | Missouri Research and Education Network | */ | ---------------------------------------------------------------------- -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
