tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Francois Arcand <>
Subject Re: [Proposal] Having a file.
Date Wed, 16 Oct 2002 21:39:29 GMT

Glenn Nielsen wrote:

> Jean-Francois Arcand wrote:
>> Hi,
>> I've re-factored and and merge the 
>> security code into a single class: 
>> This class will manage all the package access/definition security 
>> properties.
> Works for me!  You might consider moving 
> into also since it is directly related to use of the
> SecurityManager.

That's a good idea. I will do that.

> Is this change just in Tomcat 5?

Yes, but I can port easily the change in Tomcat 4 also.

>> Actually, the list of package access/definition are harcoded in that 
>> class. I would like to propose we move this package list into a 
>> 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/ file. currently contains 2 global variables: 
OK then I will leave it like that. I would consider adding a section to 
the Secutity-Manager HOW To to explain how to change those settings.

>> 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

Ya, but I have to give access to the entire package. No problem for 
Watchdog, but I prefer the public folder. This way we don't need to 
change the catalina.policy file everytime we run Watchdog.

> 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. 


I don't think they are sensitive. We have the same issue with 

> If not, perhaps
> those classes should be moved into a different package which is not
> restricted.  

+1 I think we should consider having a package in each catalina project 
where we expose classes to webapp. The easiest way be to create a 
"publicClasses" package under each sub-project. Since there is not a lot 
of classes like that, it should be easy ( I can do it). Any 
recommendation for the package name?

> 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.

I prefer the "public" package instead of doPrivilege block.

> 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,



-- Jeanfrancois

> Glenn
> ----------------------------------------------------------------------
> Glenn Nielsen    | /* Spelin donut madder    |
> MOREnet System Programming               |  * if iz ina coment.      |
> Missouri Research and Education Network  |  */                       |
> ----------------------------------------------------------------------
> --
> To unsubscribe, e-mail:   
> <>
> For additional commands, e-mail: 
> <>

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message