RE: apps conversion from 3.3.1 to 4.1.12

2002-10-10 Thread Ignacio J. Ortega

> From: news [mailto:[EMAIL PROTECTED]]On Behalf Of Costin Manolache
> Sent: Thursday, October 10, 2002 10:26 PM

> against access to resources is to use a sandbox. If you don't - 

ok, i understand, thanks..

Saludos, 
Ignacio J. Ortega 

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




Re: apps conversion from 3.3.1 to 4.1.12

2002-10-10 Thread Costin Manolache

Craig R. McClanahan wrote:

>   Keep in mind that if it works here, it will also would work
>   on something like:
> 
> InputStream stream =
>   getServletContext().getResourceAsStream("../../../etc/passwd");
> 
>   with some suitable number of ".." depending on where you've got
>   Tomcat installed.

And of course, someone could just write 

   InputStream stream=new FileInputStrea("/etc/passwd") and not 
bother with any ...

Same for any other processing done with jdni: URL paths or not.

I agree however that people shouldn't rely on resources outside
a webapplication + relative paths - that's just bad programming
in this environment. 

But it has nothing to do with security - the only way to protect
against access to resources is to use a sandbox. If you don't - 
_anything_ is possible for the user ( including System.execute("rm -rf /")).
Any restrictions on the grounds that it 'increase security' are
wrong and just give a false sense of security ( which is pretty 
dangerous in itself).

I am -1 on fixing this on 3.3 - but +1 on adding some documentation/readme 
that using this feature is not portable and will not work on other 
containers. 

-- 
Costin



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




Re: apps conversion from 3.3.1 to 4.1.12

2002-10-10 Thread Craig R. McClanahan



On Thu, 10 Oct 2002, Henri Gomez wrote:

> Date: Thu, 10 Oct 2002 08:10:03 +0200
> From: Henri Gomez <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> Subject: Re: apps conversion from 3.3.1 to 4.1.12
>
> > If this reference is in your web.xml file, then my suggestion is already
> > being done.  To test it, try temporarily copying the settings.xml file
> > into the WEB-INF directory and changing the relative URL appropriately.
>
> Putting the file in WEB-INF works, even if I use ../settings, ie
> directly in webapps/ROOT.
>
> > I'd be -1 on removing the security check in 4.x/5.x.  Fixing 3.3.2 sounds
> > like a good idea.
>
> I'll be -1 to fix the 3.3.2 for many reasons :
>
> - It will brake all deployment strategy
>
> - I'm still not sure it's a security problem since nobody prevent
>you to change to PUBLIC and goes outside :
>
> %settings;
>
> to
>
>http://hackme.com/settings.xml";>
> %settings;
>
> That's more than insecure isn't it ?
>

Not if you put the settings file inside "/WEB-INF" where it is not
accessible to external clients.

> I take a look in specs and didn't see anything preventing you to have
> entities located outside WEBAPP so I feel it's a regression and not a
> security feature.
>
> Ad minima, in TC 4.x and 5.x, there should be a setting in web.xml,
> or server.xml to enable this behaviour even if it's prevented by default.
>

-1, for at least three reasons:

* Such a path is non-sensical when you run webapps directly from
  WAR files, because the base resource (inside the WAR) does not
  have a file path.

* The URL to the base resource is being handled by a URLStreamHandler
  provided by the servlet container (the "jndi:" prefix in Tomcat 4),
  and the spec disallows access to resources outside the WAR.

* The behavior you describe would allow any webapp to snoop the entire
  directory structure of your server with a suitably construced
  relative path.  *You* may be running on an OS that supports access
  permissions (and understand how to use them), but that doesn't help
  the poor sod who uses something like Win98.

  Keep in mind that if it works here, it will also would work
  on something like:

InputStream stream =
  getServletContext().getResourceAsStream("../../../etc/passwd");

  with some suitable number of ".." depending on where you've got
  Tomcat installed.

Craig



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>




Re: apps conversion from 3.3.1 to 4.1.12

2002-10-09 Thread Henri Gomez

> If this reference is in your web.xml file, then my suggestion is already
> being done.  To test it, try temporarily copying the settings.xml file
> into the WEB-INF directory and changing the relative URL appropriately.

Putting the file in WEB-INF works, even if I use ../settings, ie 
directly in webapps/ROOT.

> I'd be -1 on removing the security check in 4.x/5.x.  Fixing 3.3.2 sounds
> like a good idea.

I'll be -1 to fix the 3.3.2 for many reasons :

- It will brake all deployment strategy

- I'm still not sure it's a security problem since nobody prevent
   you to change to PUBLIC and goes outside :

%settings;

to

   http://hackme.com/settings.xml";> 
%settings;

That's more than insecure isn't it ?

I take a look in specs and didn't see anything preventing you to have 
entities located outside WEBAPP so I feel it's a regression and not a
security feature.

Ad minima, in TC 4.x and 5.x, there should be a setting in web.xml,
or server.xml to enable this behaviour even if it's prevented by default.





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




Re: apps conversion from 3.3.1 to 4.1.12

2002-10-09 Thread Craig R. McClanahan



On Wed, 9 Oct 2002, Henri Gomez wrote:

> Date: Wed, 09 Oct 2002 18:13:10 +0200
> From: Henri Gomez <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> Subject: Re: apps conversion from 3.3.1 to 4.1.12
>
>
> > Haven't looked at the code, but here's a couple of thoughts that might
> > help:
> >
> > If your path above ("../../../settings.xml") is attempting to go above
> > the context root of the webapp, it's pretty much guaranteed to fail
> > because of the security restrictions.  Undoing that restriction would just
> > create a bunch of CERT reports about Tomcat letting you browse the entire
> > directory structure of your disk.
>
> I agree but the ../../../settings.xml was set in web.xml, under
> administrator control, and tomcat can't even overwrite it.
>
> We've got another problem here since Tomcat 3.3.x allow this and but
> Tomcat 4.1.x prevent it. Should we fix Tomcat 3.3.2 ?
>
> > One of the important enablers for using external entity files in Digester
> > is to use the Digester.parse() that takes an InputSource (rather than an
> > InputStream), and be sure you have configured your InputSource to include
> > the source URL.  That is necessary for the XML parser to be able to
> > resolve relative system ids.  The code in ContextConfig that parses
> > web.xml and TLD files was modified (a while back) to do this kind of
> > thing, if you need an example.
>
> Didn't have access on it since the external entity is set in web.xml so
> under org.apache.catalina.startup.ContextConfig.applicationConfig
> control, not application control.
>

If this reference is in your web.xml file, then my suggestion is already
being done.  To test it, try temporarily copying the settings.xml file
into the WEB-INF directory and changing the relative URL appropriately.

I'd be -1 on removing the security check in 4.x/5.x.  Fixing 3.3.2 sounds
like a good idea.

Craig


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>




Re: apps conversion from 3.3.1 to 4.1.12

2002-10-09 Thread Henri Gomez


> Haven't looked at the code, but here's a couple of thoughts that might
> help:
> 
> If your path above ("../../../settings.xml") is attempting to go above
> the context root of the webapp, it's pretty much guaranteed to fail
> because of the security restrictions.  Undoing that restriction would just
> create a bunch of CERT reports about Tomcat letting you browse the entire
> directory structure of your disk.

I agree but the ../../../settings.xml was set in web.xml, under 
administrator control, and tomcat can't even overwrite it.

We've got another problem here since Tomcat 3.3.x allow this and but
Tomcat 4.1.x prevent it. Should we fix Tomcat 3.3.2 ?

> One of the important enablers for using external entity files in Digester
> is to use the Digester.parse() that takes an InputSource (rather than an
> InputStream), and be sure you have configured your InputSource to include
> the source URL.  That is necessary for the XML parser to be able to
> resolve relative system ids.  The code in ContextConfig that parses
> web.xml and TLD files was modified (a while back) to do this kind of
> thing, if you need an example.

Didn't have access on it since the external entity is set in web.xml so
under org.apache.catalina.startup.ContextConfig.applicationConfig 
control, not application control.



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




Re: apps conversion from 3.3.1 to 4.1.12

2002-10-09 Thread Henri Gomez

>> 
>org.apache.naming.resources.DirContextURLConnection.getInputStream(DirContextURLConnection.java:344)
> 
>>
>> at java.net.URL.openStream(URL.java:793)
> 
> 
> Well, that's exactly the same. Where do you think that weird URL 
> connection goes ?? (hint: to the aforementioned FileDirContext, through 
> some classloader binding)

Well it's my initial diggs in TC 4.1.x, let me some time to discover it.

> The place where it gets rejected should be the FileDirContext.file() 
> method, as far as I can remember.

FileDirContext.file() is used to get webapps/ROOT/web.xml ref and
validate access, but the external entity is grabbed from Digester
so outside FileDirContext control (from my debug analyze).



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




Re: apps conversion from 3.3.1 to 4.1.12

2002-10-09 Thread Remy Maucherat

Henri Gomez wrote:
> Remy Maucherat wrote:
> 
>> Henri Gomez wrote:
>>
 This is likely the protection against reading anything outside the 
 webapp root (see the "allowLinking" of FileDirContext), although I 
 don't know how the digester will try to load the included file.
>>>
>>>
>>>
>>>
>>> Digester code is derived from XmlMapper which is able to locate 
>>> entities in ../../../ directories.
>>>
>>> My concern here is :
>>>
>>> Specs didn't mentions restriction on use of external entities outside 
>>> the webapp.
>>>
>>> So it should be granted by default isn't it ?
>>>
>>> I take a look at FileDirContext but I didn't understand what 
>>> allowLinking is ?
>>
>>
>>  >
>>
>>> So my question is : bug or feature ?
>>
>>
>>
>> There's a pretty strict check on the canonical path of a resource 
>> which I added.
>> I consider it a security feature. I think a webapp should be self 
>> contained, so I think it's reasonable to have the check as the default.
>>
>> "allowLinking" disables the check.
>>
>> Don't be lazy, just do a search in FileDirContext ;-)
> 
> 
> I take a look at this but but digester didn't use FileDirContext so the 
> allowLinking didn't fit.
> 
> The problem seems be only in Digester which fail to load 
> ../../../settings.xml
> 
> What could we do ?
> 
> PS: I tried with TC 4.1.x and all commons from CVS.
> 
> 
> at 
> 
>org.apache.naming.resources.DirContextURLConnection.getInputStream(DirContextURLConnection.java:344)
> 
> 
> at java.net.URL.openStream(URL.java:793)

Well, that's exactly the same. Where do you think that weird URL 
connection goes ?? (hint: to the aforementioned FileDirContext, through 
some classloader binding)

The place where it gets rejected should be the FileDirContext.file() 
method, as far as I can remember.

Remy


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




Re: apps conversion from 3.3.1 to 4.1.12

2002-10-09 Thread Craig R. McClanahan



On Wed, 9 Oct 2002, Henri Gomez wrote:

> Date: Wed, 09 Oct 2002 17:39:00 +0200
> From: Henri Gomez <[EMAIL PROTECTED]>
> Reply-To: Tomcat Developers List <[EMAIL PROTECTED]>
> To: Tomcat Developers List <[EMAIL PROTECTED]>
> Subject: Re: apps conversion from 3.3.1 to 4.1.12
>
> Remy Maucherat wrote:
> > Henri Gomez wrote:
> >
> >>> This is likely the protection against reading anything outside the
> >>> webapp root (see the "allowLinking" of FileDirContext), although I
> >>> don't know how the digester will try to load the included file.
> >>
> >>
> >>
> >> Digester code is derived from XmlMapper which is able to locate
> >> entities in ../../../ directories.
> >>
> >> My concern here is :
> >>
> >> Specs didn't mentions restriction on use of external entities outside
> >> the webapp.
> >>
> >> So it should be granted by default isn't it ?
> >>
> >> I take a look at FileDirContext but I didn't understand what
> >> allowLinking is ?
> >
> >  >
> >
> >> So my question is : bug or feature ?
> >
> >
> > There's a pretty strict check on the canonical path of a resource which
> > I added.
> > I consider it a security feature. I think a webapp should be self
> > contained, so I think it's reasonable to have the check as the default.
> >
> > "allowLinking" disables the check.
> >
> > Don't be lazy, just do a search in FileDirContext ;-)
>
> I take a look at this but but digester didn't use FileDirContext so the
> allowLinking didn't fit.
>
> The problem seems be only in Digester which fail to load
> ../../../settings.xml
>
> What could we do ?
>

Haven't looked at the code, but here's a couple of thoughts that might
help:

If your path above ("../../../settings.xml") is attempting to go above
the context root of the webapp, it's pretty much guaranteed to fail
because of the security restrictions.  Undoing that restriction would just
create a bunch of CERT reports about Tomcat letting you browse the entire
directory structure of your disk.

One of the important enablers for using external entity files in Digester
is to use the Digester.parse() that takes an InputSource (rather than an
InputStream), and be sure you have configured your InputSource to include
the source URL.  That is necessary for the XML parser to be able to
resolve relative system ids.  The code in ContextConfig that parses
web.xml and TLD files was modified (a while back) to do this kind of
thing, if you need an example.

> PS: I tried with TC 4.1.x and all commons from CVS.
>

Craig

>
>   at
> 
>org.apache.naming.resources.DirContextURLConnection.getInputStream(DirContextURLConnection.java:344)
>   at java.net.URL.openStream(URL.java:793)
>   at
> org.apache.xerces.impl.XMLEntityManager.startEntity(XMLEntityManager.java:807)
>   at
> org.apache.xerces.impl.XMLEntityManager.startEntity(XMLEntityManager.java:738)
>   at
> org.apache.xerces.impl.XMLDTDScannerImpl.startPE(XMLDTDScannerImpl.java:609)
>   at
> org.apache.xerces.impl.XMLDTDScannerImpl.skipSeparator(XMLDTDScannerImpl.java:1927)
>   at
> org.apache.xerces.impl.XMLDTDScannerImpl.scanDecls(XMLDTDScannerImpl.java:1889)
>   at
> 
>org.apache.xerces.impl.XMLDTDScannerImpl.scanDTDInternalSubset(XMLDTDScannerImpl.java:359)
>   at
> 
>org.apache.xerces.impl.XMLDocumentScannerImpl$DTDDispatcher.dispatch(XMLDocumentScannerImpl.java:808)
>   at
> 
>org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:329)
>   at
> org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:525)
>   at
> org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:581)
>   at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:152)
>   at
> org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1175)
>   at org.apache.commons.digester.Digester.parse(Digester.java:1542)
>   at
> org.apache.catalina.startup.ContextConfig.applicationConfig(ContextConfig.java:282)
>   at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:639)
>   at
> org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:243)
>   at
> 
>org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166)
>   at
> org.apache.catalina.core.StandardContext.start(StandardContext.java:3567)
>   at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:11

Re: apps conversion from 3.3.1 to 4.1.12

2002-10-09 Thread Henri Gomez

Remy Maucherat wrote:
> Henri Gomez wrote:
> 
>>> This is likely the protection against reading anything outside the 
>>> webapp root (see the "allowLinking" of FileDirContext), although I 
>>> don't know how the digester will try to load the included file.
>>
>>
>>
>> Digester code is derived from XmlMapper which is able to locate 
>> entities in ../../../ directories.
>>
>> My concern here is :
>>
>> Specs didn't mentions restriction on use of external entities outside 
>> the webapp.
>>
>> So it should be granted by default isn't it ?
>>
>> I take a look at FileDirContext but I didn't understand what 
>> allowLinking is ?
> 
>  >
> 
>> So my question is : bug or feature ?
> 
> 
> There's a pretty strict check on the canonical path of a resource which 
> I added.
> I consider it a security feature. I think a webapp should be self 
> contained, so I think it's reasonable to have the check as the default.
> 
> "allowLinking" disables the check.
> 
> Don't be lazy, just do a search in FileDirContext ;-)

I take a look at this but but digester didn't use FileDirContext so the 
allowLinking didn't fit.

The problem seems be only in Digester which fail to load 
../../../settings.xml

What could we do ?

PS: I tried with TC 4.1.x and all commons from CVS.


at 
org.apache.naming.resources.DirContextURLConnection.getInputStream(DirContextURLConnection.java:344)
at java.net.URL.openStream(URL.java:793)
at 
org.apache.xerces.impl.XMLEntityManager.startEntity(XMLEntityManager.java:807)
at 
org.apache.xerces.impl.XMLEntityManager.startEntity(XMLEntityManager.java:738)
at 
org.apache.xerces.impl.XMLDTDScannerImpl.startPE(XMLDTDScannerImpl.java:609)
at 
org.apache.xerces.impl.XMLDTDScannerImpl.skipSeparator(XMLDTDScannerImpl.java:1927)
at 
org.apache.xerces.impl.XMLDTDScannerImpl.scanDecls(XMLDTDScannerImpl.java:1889)
at 
org.apache.xerces.impl.XMLDTDScannerImpl.scanDTDInternalSubset(XMLDTDScannerImpl.java:359)
at 
org.apache.xerces.impl.XMLDocumentScannerImpl$DTDDispatcher.dispatch(XMLDocumentScannerImpl.java:808)
at 
org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:329)
at 
org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:525)
at 
org.apache.xerces.parsers.DTDConfiguration.parse(DTDConfiguration.java:581)
at org.apache.xerces.parsers.XMLParser.parse(XMLParser.java:152)
at 
org.apache.xerces.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1175)
at org.apache.commons.digester.Digester.parse(Digester.java:1542)
at 
org.apache.catalina.startup.ContextConfig.applicationConfig(ContextConfig.java:282)
at org.apache.catalina.startup.ContextConfig.start(ContextConfig.java:639)
at 
org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:243)
at 
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166)
at 
org.apache.catalina.core.StandardContext.start(StandardContext.java:3567)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:738)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1188)
at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:347)
at org.apache.catalina.core.StandardService.start(StandardService.java:497)










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




Re: apps conversion from 3.3.1 to 4.1.12

2002-10-09 Thread Remy Maucherat

Henri Gomez wrote:
>> This is likely the protection against reading anything outside the 
>> webapp root (see the "allowLinking" of FileDirContext), although I 
>> don't know how the digester will try to load the included file.
> 
> 
> Digester code is derived from XmlMapper which is able to locate entities 
> in ../../../ directories.
> 
> My concern here is :
> 
> Specs didn't mentions restriction on use of external entities outside 
> the webapp.
> 
> So it should be granted by default isn't it ?
> 
> I take a look at FileDirContext but I didn't understand what 
> allowLinking is ?
 >
> So my question is : bug or feature ?

There's a pretty strict check on the canonical path of a resource which 
I added.
I consider it a security feature. I think a webapp should be self 
contained, so I think it's reasonable to have the check as the default.

"allowLinking" disables the check.

Don't be lazy, just do a search in FileDirContext ;-)

Remy


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




Re: apps conversion from 3.3.1 to 4.1.12

2002-10-09 Thread Henri Gomez

> This is likely the protection against reading anything outside the 
> webapp root (see the "allowLinking" of FileDirContext), although I don't 
> know how the digester will try to load the included file.

Digester code is derived from XmlMapper which is able to locate entities 
in ../../../ directories.

My concern here is :

Specs didn't mentions restriction on use of external entities outside 
the webapp.

So it should be granted by default isn't it ?

I take a look at FileDirContext but I didn't understand what 
allowLinking is ?

So my question is : bug or feature ?


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




Re: apps conversion from 3.3.1 to 4.1.12

2002-10-09 Thread Remy Maucherat

Henri Gomez wrote:
>>> While converting some applications from 3.3.1 to 4.1.12 I noticed
>>> some little problems.
>>
>>
>>
>> Wot? 3.3.1 isn't good enough for you any more. ;-)
> 
> 
> You're kidding, I'm preparing the future, which may be TC 5 for us
> if we could avoid JDK 1.4 to be mandatory.
> 
> And I'd like to do some internals benchmarks ;)

You can publish them if you want to (I think JDK 1.4.1 is supposed to 
give the best results with TC 4.1.x).
BTW, I added a document on benchmarks in TC 5. Feel free to modify it.

Remy


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




Re: apps conversion from 3.3.1 to 4.1.12

2002-10-09 Thread Henri Gomez

>>While converting some applications from 3.3.1 to 4.1.12 I noticed
>>some little problems.
> 
> 
> Wot? 3.3.1 isn't good enough for you any more. ;-)

You're kidding, I'm preparing the future, which may be TC 5 for us
if we could avoid JDK 1.4 to be mandatory.

And I'd like to do some internals benchmarks ;)

> Without testing, in theory you can put your jar in common/lib, and change
> the classname for "default" in conf/web.xml and the only bugs will be yours.
> :)  Note, that this is more than you can do with 3.3.1.
> 
> 
>>2) We also used to include external entities in web.xml which live
>>outside webapp dir :
>>
>>ie :
>>
>>
>>>2.2//EN"
>>  "http://java.sun.com/j2ee/dtds/web-app_2.2.dtd";
> 
> [
> 
>> %settings;
>>]>
>>
>>...
>>
>>Digester find settings.xml only when it's located in WEB-INF or
>>webapp directories (ie ROOT/WEB-INF/settings.xml or ROOT/settings.xml).
>>
>>How could I make it find the settings.xml outside webapps area ?
>>via conf/catalina.policy ?
>>
> 
> 
> This has always been a headache for me on all Tomcat versions.  However, I
> don't think that internal-entities can be used at all (usefully).

When you need to set some properties outside webapps, ie system settings
used by web applications, you need it.



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




Re: apps conversion from 3.3.1 to 4.1.12

2002-10-08 Thread Bill Barker


- Original Message -
From: "Henri Gomez" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, October 08, 2002 11:33 PM
Subject: apps conversion from 3.3.1 to 4.1.12


> Hi to all,
>
> While converting some applications from 3.3.1 to 4.1.12 I noticed
> some little problems.

Wot? 3.3.1 isn't good enough for you any more. ;-)

>
> 1) We used to define our own default servlet, but 4.1.x
> definie its own default in conf/web.xml.
>
> Could we change from org.apache.catalina.servlets.DefaultServlet
> to our actual default servlet, knowing that all webapps use the
> same code base ? In that case should the jar containing the
> default servlet could be in common/lib ?

Without testing, in theory you can put your jar in common/lib, and change
the classname for "default" in conf/web.xml and the only bugs will be yours.
:)  Note, that this is more than you can do with 3.3.1.

>
> 2) We also used to include external entities in web.xml which live
> outside webapp dir :
>
> ie :
>
> 
>  2.2//EN"
>   "http://java.sun.com/j2ee/dtds/web-app_2.2.dtd";
[
>  %settings;
> ]>
>
> ...
>
> Digester find settings.xml only when it's located in WEB-INF or
> webapp directories (ie ROOT/WEB-INF/settings.xml or ROOT/settings.xml).
>
> How could I make it find the settings.xml outside webapps area ?
> via conf/catalina.policy ?
>

This has always been a headache for me on all Tomcat versions.  However, I
don't think that internal-entities can be used at all (usefully).

>
> Thanks for you help.
>
>
>
> --
> To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>
>


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>




Re: apps conversion from 3.3.1 to 4.1.12

2002-10-08 Thread Henri Gomez

Remy Maucherat wrote:
> Henri Gomez wrote:
> 
>> Hi to all,
>>
>> While converting some applications from 3.3.1 to 4.1.12 I noticed
>> some little problems.
>>
>> 1) We used to define our own default servlet, but 4.1.x
>>definie its own default in conf/web.xml.
>>
>>Could we change from org.apache.catalina.servlets.DefaultServlet
>>to our actual default servlet, knowing that all webapps use the
>>same code base ? In that case should the jar containing the
>>default servlet could be in common/lib ?
> 
> 
> AFAIK, yes. You should be able to put it in shared/lib.
> The webapp settings also override the global settings.

Great.

>> 2) We also used to include external entities in web.xml which live
>>outside webapp dir :
>>
>>ie :
>>
>> 
>> > Application 2.2//EN"
>>  
>> "http://java.sun.com/j2ee/dtds/web-app_2.2.dtd"; [
>>  %settings;
>> ]>
>>
>> ...
>>
>> Digester find settings.xml only when it's located in WEB-INF or
>> webapp directories (ie ROOT/WEB-INF/settings.xml or ROOT/settings.xml).
>>
>> How could I make it find the settings.xml outside webapps area ?
>> via conf/catalina.policy ?
> 
> 
> This is likely the protection against reading anything outside the 
> webapp root (see the "allowLinking" of FileDirContext), although I don't 
> know how the digester will try to load the included file.

I'll check for it, thanks.




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




Re: apps conversion from 3.3.1 to 4.1.12

2002-10-08 Thread Remy Maucherat

Henri Gomez wrote:
> Hi to all,
> 
> While converting some applications from 3.3.1 to 4.1.12 I noticed
> some little problems.
> 
> 1) We used to define our own default servlet, but 4.1.x
>definie its own default in conf/web.xml.
> 
>Could we change from org.apache.catalina.servlets.DefaultServlet
>to our actual default servlet, knowing that all webapps use the
>same code base ? In that case should the jar containing the
>default servlet could be in common/lib ?

AFAIK, yes. You should be able to put it in shared/lib.
The webapp settings also override the global settings.

> 2) We also used to include external entities in web.xml which live
>outside webapp dir :
> 
>ie :
> 
> 
>  2.2//EN"
>  "http://java.sun.com/j2ee/dtds/web-app_2.2.dtd"; [
>  %settings;
> ]>
> 
> ...
> 
> Digester find settings.xml only when it's located in WEB-INF or
> webapp directories (ie ROOT/WEB-INF/settings.xml or ROOT/settings.xml).
> 
> How could I make it find the settings.xml outside webapps area ?
> via conf/catalina.policy ?

This is likely the protection against reading anything outside the 
webapp root (see the "allowLinking" of FileDirContext), although I don't 
know how the digester will try to load the included file.

Remy


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




apps conversion from 3.3.1 to 4.1.12

2002-10-08 Thread Henri Gomez

Hi to all,

While converting some applications from 3.3.1 to 4.1.12 I noticed
some little problems.

1) We used to define our own default servlet, but 4.1.x
definie its own default in conf/web.xml.

Could we change from org.apache.catalina.servlets.DefaultServlet
to our actual default servlet, knowing that all webapps use the
same code base ? In that case should the jar containing the
default servlet could be in common/lib ?

2) We also used to include external entities in web.xml which live
outside webapp dir :

ie :


http://java.sun.com/j2ee/dtds/web-app_2.2.dtd"; [
 %settings;
]>

...

Digester find settings.xml only when it's located in WEB-INF or
webapp directories (ie ROOT/WEB-INF/settings.xml or ROOT/settings.xml).

How could I make it find the settings.xml outside webapps area ?
via conf/catalina.policy ?


Thanks for you help.



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