tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn Nielsen <gl...@mail.more.net>
Subject Re: [Proposal] Having a Tomcat.security file.
Date Wed, 16 Oct 2002 21:15:42 GMT
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             glenn@more.net | /* Spelin donut madder    |
MOREnet System Programming               |  * if iz ina coment.      |
Missouri Research and Education Network  |  */                       |
----------------------------------------------------------------------


--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message