atom feed6 messages in org.apache.shale.devAW: Security in Remoting: ClassResour...
FromSent OnAttachments
Bernhard SlominskiNov 29, 2006 5:40 am 
Hermod OpstvedtNov 29, 2006 9:33 am 
Craig McClanahanNov 29, 2006 11:48 am 
Bernhard SlominskiNov 29, 2006 10:11 pm 
Craig McClanahanNov 30, 2006 3:07 pm 
Bernhard SlominskiDec 1, 2006 5:30 am 
Subject:AW: Security in Remoting: ClassResourceProcessor
From:Bernhard Slominski (bern@zooplus.com)
Date:Nov 29, 2006 10:11:20 pm
List:org.apache.shale.dev

Thanks for considering my issue. I think many are people are just not aware of this issue because they use another part of the Shale framwork and are not familiar with the details of the ClassRessourceProcssor, that why it should be explicitly enabled. As Hermond pointed out you should not have secure data unencyrtped in files but I saw many people do that. What we don't want is that some applications get in trouble and people say that Shale is a security risk to your application.

Bernhard

-----Ursprüngliche Nachricht----- Von: crai@gmail.com [mailto:crai@gmail.com]Im Auftrag von Craig McClanahan Gesendet: Mittwoch, 29. November 2006 20:49 An: de@shale.apache.org Betreff: Re: Security in Remoting: ClassResourceProcessor

On 11/29/06, Bernhard Slominski <bern@zooplus.com> wrote:

Hi,

I think the current implementation of the ClassResourceProcessor is a security issue. The ClassResourceProcessor exposes all files in the classpath and it's enable by default. If you have e.g. your database passwords in properties files you just have to know the name and path to the file and you can read the content of the file. So I think it should at least be disabled by default.

It doesn't allow access to Java class files, but your point is well taken ... we need mechanisms to control which resources are allowed. (You can use web.xml security constraints to partially do this, but the set of supported URL patterns is somewhat limited.)

Bernhard

Craig