Re: [OT] Re: Question about DirResourceSet?

2019-10-20 Thread Mark Thomas
> Mark,
> 
> On 10/16/19 04:41, Mark Thomas wrote:
>>> On 10/15/19 09:37, Mark Thomas wrote:



>>> Isn't there a magic ${property} that can be used to mean "the
>>> context's root" so you don't have to use ${catalina.base}
>>> instead? I browsed  through the document a bit and didn't find
>>> anything, but I could swear it's been discussed in the past.
> 
>> There has been some discussion about exposing the context name via
>> additional routes but I don't remember anything specific about the
>> context root - apart from various discussions around getRealPath()
>> and not being able to assume that any web app maps to a location on
>> a file system.
> 
> Right, getRealPath is the badness.
> 
> But! Since all resource loading in Tomcat now goes through the
> resources framework, perhaps "${context-root}" could use a proper
> protocol that isn't "file:///" and point to the right place?

Well, the server.xml parsing should accept URLs anywhere you can specify
a file (assuming we've hooked up everything correctly) so you could
probably have ${context-root} return the result of
WebResourceRoot.getResource("/").getURL()

However...

That is only going to work *after* the web application has started but
you need it *before* the app starts to use it in context.xml.

I think this might end up being one of those cases where using
${catalina.base} is the better approach.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: [OT] Re: Question about DirResourceSet?

2019-10-16 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 10/16/19 04:41, Mark Thomas wrote:
>> Mark,
>>
>> On 10/15/19 09:37, Mark Thomas wrote:
>>> On 14/10/2019 20:29, André Warnier (tomcat) wrote:
 From a long-time (occasional) list contributor : That's a
 nice post, in many ways, and a good way to get quick and
 useful answers. I only regret that my own knowledge is not
 sufficient to provide such an answer. (We regularly complain
 at people posting to this list, when their post is "not
 nice", so I thought we should also from time to time give
 kudos when it is).
>>
>>> +1
>>
 On 14.10.2019 16:37, Robert Olofsson wrote:
> Hi!
>
> Some background: We are currently running tomcat (9.0.26)
> and we serve data to both html/webapp and to our java
> application. The java application uses a lot of the same
> jar files that our servlets use.
>
> We have had tomcat setup with two directories: 1)
> webapps//WEB-INF/lib (as usual for servlet classes)
> 2) webapps//clientdir/ (jar files for the java
> application).
>
> This means that we have a lot of duplication of jar files
> in these two directories.
>
> We would like to have the duplicate files in only one
> place, sure disk space is cheap, but data transfer takes
> time. We thought that having the jars in the clientdir
> would be nice.
>
> We have read the documentation for tomcat and found the
> resource handling and it looks like we could possibly use
> something like:
>
>   base="${catalina.base}/webapps//clientdir/"
> className="org.apache.catalina.webresources.DirResourceSet"
>
>
webAppMount="/WEB-INF/lib" /> 
>
> We tested this lightly and things seems to work.
>
> Questions: Is there any problem with this?
>>
>>> Generally, no. You've done it in what I'd consider to be the
>>> "safer" way by exposing all the JARs visible to the client to
>>> the application's class loader rather than the other way
>>> around.
>>
>> Isn't there a magic ${property} that can be used to mean "the
>> context's root" so you don't have to use ${catalina.base}
>> instead? I browsed  through the document a bit and didn't find
>> anything, but I could swear it's been discussed in the past.
>
> There has been some discussion about exposing the context name via
> additional routes but I don't remember anything specific about the
> context root - apart from various discussions around getRealPath()
> and not being able to assume that any web app maps to a location on
> a file system.

Right, getRealPath is the badness.

But! Since all resource loading in Tomcat now goes through the
resources framework, perhaps "${context-root}" could use a proper
protocol that isn't "file:///" and point to the right place?

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2naqYACgkQHPApP6U8
pFgAXA//Z/IlqTRKyuXgBQUFB1UlnYesICkN+1IvLNYeo/ooNoxNpoBHw0Wkotkt
KJ1R+QNrJ9U/kPZ7lLe0eng5fLtv2kuTX1ZhqyOuqCRTnb+Knl3I3EiZ7czgX1RK
v+Y99EMCKg5aVXj1n9fB9Qha+WMD0JI729Qr0kPd7WPmhbLcLXts7/aqAAU1+7zs
hZDUNB9eW+eV+f3nkA0mjJBzj18sLdNpvn1oxUwFr70YaZenXb7kIb2zueGVloOw
X1378Yr3txvPb03T9mwcEZ5PyZ+NJgVvoL0HB5N+K67X1DiBGPolOWVw6lUjNQmt
+nSEvrBz2jkVbl9MLVj9soGborgNZpFAE88T73qTj3Ky88uxgVn8gy4wQirynEEA
ggBdjrybi2Ecl9gjgmrkY+EjFVndWFq0kykkLPPIAWalIGM0eDL+LXGpORRQ7VNx
QQfPGmbSF6QahRBFx+wdxLziIT++QZJgZFQO49eWyID4okAaoW4U5ml4oHEj602i
0Ab1YXEuH8+tCiyklgIQYiU1bW2WW1281Lml9m399jTTKzaW/A4/ZpEM4Ak4Pj8q
X6Sigo3AK7aBT7TrPpx/GHbkM53lA6pBYERp156iFCYecVOjwUNSWrtY8Z0gLnQi
6vriV9z8WWFD2FdZ3WDVS3FTpfJbE8jONZZugQbrIKN5yTj1Ves=
=gSFg
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: [OT] Re: Question about DirResourceSet?

2019-10-16 Thread Mark Thomas
> Mark,
> 
> On 10/15/19 09:37, Mark Thomas wrote:
>> On 14/10/2019 20:29, André Warnier (tomcat) wrote:
>>> From a long-time (occasional) list contributor : That's a nice
>>> post, in many ways, and a good way to get quick and useful
>>> answers. I only regret that my own knowledge is not sufficient to
>>> provide such an answer. (We regularly complain at people posting
>>> to this list, when their post is "not nice", so I thought we
>>> should also from time to time give kudos when it is).
> 
>> +1
> 
>>> On 14.10.2019 16:37, Robert Olofsson wrote:
 Hi!

 Some background: We are currently running tomcat (9.0.26) and
 we serve data to both html/webapp and to our java application.
 The java application uses a lot of the same jar files that our
 servlets use.

 We have had tomcat setup with two directories: 1)
 webapps//WEB-INF/lib (as usual for servlet classes) 2)
 webapps//clientdir/ (jar files for the java
 application).

 This means that we have a lot of duplication of jar files in
 these two directories.

 We would like to have the duplicate files in only one place,
 sure disk space is cheap, but data transfer takes time. We
 thought that having the jars in the clientdir would be nice.

 We have read the documentation for tomcat and found the
 resource handling and it looks like we could possibly use
 something like:

  >>> base="${catalina.base}/webapps//clientdir/"
 className="org.apache.catalina.webresources.DirResourceSet"
 webAppMount="/WEB-INF/lib" /> 

 We tested this lightly and things seems to work.

 Questions: Is there any problem with this?
> 
>> Generally, no. You've done it in what I'd consider to be the
>> "safer" way by exposing all the JARs visible to the client to the
>> application's class loader rather than the other way around.
> 
> Isn't there a magic ${property} that can be used to mean "the
> context's root" so you don't have to use ${catalina.base} instead? I
> browsed  through the document a bit and didn't find anything, but I
> could swear it's been discussed in the past.

There has been some discussion about exposing the context name via
additional routes but I don't remember anything specific about the
context root - apart from various discussions around getRealPath() and
not being able to assume that any web app maps to a location on a file
system.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: [OT] Re: Question about DirResourceSet?

2019-10-15 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 10/15/19 09:37, Mark Thomas wrote:
> On 14/10/2019 20:29, André Warnier (tomcat) wrote:
>> From a long-time (occasional) list contributor : That's a nice
>> post, in many ways, and a good way to get quick and useful
>> answers. I only regret that my own knowledge is not sufficient to
>> provide such an answer. (We regularly complain at people posting
>> to this list, when their post is "not nice", so I thought we
>> should also from time to time give kudos when it is).
>
> +1
>
>> On 14.10.2019 16:37, Robert Olofsson wrote:
>>> Hi!
>>>
>>> Some background: We are currently running tomcat (9.0.26) and
>>> we serve data to both html/webapp and to our java application.
>>> The java application uses a lot of the same jar files that our
>>> servlets use.
>>>
>>> We have had tomcat setup with two directories: 1)
>>> webapps//WEB-INF/lib (as usual for servlet classes) 2)
>>> webapps//clientdir/ (jar files for the java
>>> application).
>>>
>>> This means that we have a lot of duplication of jar files in
>>> these two directories.
>>>
>>> We would like to have the duplicate files in only one place,
>>> sure disk space is cheap, but data transfer takes time. We
>>> thought that having the jars in the clientdir would be nice.
>>>
>>> We have read the documentation for tomcat and found the
>>> resource handling and it looks like we could possibly use
>>> something like:
>>>
>>>  >> base="${catalina.base}/webapps//clientdir/"
>>> className="org.apache.catalina.webresources.DirResourceSet"
>>> webAppMount="/WEB-INF/lib" /> 
>>>
>>> We tested this lightly and things seems to work.
>>>
>>> Questions: Is there any problem with this?
>
> Generally, no. You've done it in what I'd consider to be the
> "safer" way by exposing all the JARs visible to the client to the
> application's class loader rather than the other way around.

Isn't there a magic ${property} that can be used to mean "the
context's root" so you don't have to use ${catalina.base} instead? I
browsed  through the document a bit and didn't find anything, but I
could swear it's been discussed in the past.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl2mGvYACgkQHPApP6U8
pFgdjg/9GKn1rTf5hXozVinl6tiVD9RJGi9mC/+zzLtUJOsb2/LNGsjd7CcVNP/S
IgnlbQun9SQtyK8mSd3cQXwenrKY5mkFta12cgc1FMuuLBT3m74WPWcv+OLo1HKd
+yTgkSak9i4U+zV4sP/RfusKW3FgYU9UJRIE/I/wWXt6fSrc7pEtH12qdH9gauH2
itvo4XtJNsNq3RADqdf79vz/oL5+90n3OB29/L7ocO5p8tEiHF1W95Mt1hVwo0Re
rYi5Rv8MesTkw35K2GYWFzV9TndiOGiI7uH3GW8Y/7wXoNecXmL4XuFLiNUsTXhI
XRrLsLl6qwxagan627Q1TW7SMMfsu7h3M1you1qe/wB8PB3MIZ6mvAbyIFKXxw2j
zt0iuYWsZppM6ZKU4nr8//Q+icDLgJIHwKxk/OlpLNahmThmSn4bml9IML3R7m0H
TWMezbuL4QPSTMhMywKVAdMH5IMQe3jO1pXVsrgJmAj6YaCqQy87rilYf+5xGpRo
pTtgOYV/pKk/YCTAB88O4EkgMwbwhFxa2mbsYIX12RCWm5EevmacBQ6cv5oZdTDS
mVIRWeMUxDjCM1tHLIMFv2/xDo+BINiVmWLEpvuqddsO65399xERdTDMqeRJehSm
lg0sIlrne8ankbkGPxIi5iRLqCt4dVID86kkehEZov8xM2px6iU=
=Mbci
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: [OT] Re: Question about DirResourceSet?

2019-10-15 Thread Robert Olofsson
Hi!

On Tue, 2019-10-15 at 14:37 +0100, Mark Thomas wrote:
> Generally, no. You've done it in what I'd consider to be the "safer" way
> by exposing all the JARs visible to the client to the application's
> class loader rather than the other way around. 

Ok, good to hear, we will try this and see how things work out.
I am happy to hear that you reflected about security and as far as
I know we do not have any upload into the web app (and I ought to 
know if we do :-). Security was one of the main reason for my questions.

> another option would be to use a ServletContextListener to copy the
> files...

Sure, but just pointing out another directory is a lot easier.

Thanks a lot.
/robo



-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



Re: [OT] Re: Question about DirResourceSet?

2019-10-15 Thread Mark Thomas
On 14/10/2019 20:29, André Warnier (tomcat) wrote:
> From a long-time (occasional) list contributor :
> That's a nice post, in many ways, and a good way to get quick and useful
> answers.
> I only regret that my own knowledge is not sufficient to provide such an
> answer.
> (We regularly complain at people posting to this list, when their post
> is "not nice", so I thought we should also from time to time give kudos
> when it is).

+1

> On 14.10.2019 16:37, Robert Olofsson wrote:
>> Hi!
>>
>> Some background:
>> We are currently running tomcat (9.0.26) and we serve data to
>> both html/webapp and to our java application. The java application
>> uses a lot of the same jar files that our servlets use.
>>
>> We have had tomcat setup with two directories:
>> 1) webapps//WEB-INF/lib (as usual for servlet classes)
>> 2) webapps//clientdir/ (jar files for the java application).
>>
>> This means that we have a lot of duplication of jar files in these two
>> directories.
>>
>> We would like to have the duplicate files in only one place, sure
>> disk space is cheap, but data transfer takes time. We thought that
>> having the jars in the clientdir would be nice.
>>
>> We have read the documentation for tomcat and found the resource handling
>> and it looks like we could possibly use something like:
>>
>> 
>>    >  className="org.apache.catalina.webresources.DirResourceSet"
>>  webAppMount="/WEB-INF/lib" />
>> 
>>
>> We tested this lightly and things seems to work.
>>
>> Questions:
>> Is there any problem with this?

Generally, no. You've done it in what I'd consider to be the "safer" way
by exposing all the JARs visible to the client to the application's
class loader rather than the other way around.

If applications can upload files then, depending on how that is
configured, you might have opened a remote code execution vulnerability.
But then, if clients can upload arbitrary files into the web app you
likely have an RCE issue anyway (via an uploaded JSP) irrespective of
how you handle JARs.

>> If so, do you know of any better way to accomplish this?

Depending on how early the classes in those JARs might be required,
another option would be to use a ServletContextListener to copy the
files from the app to the WEB-INF/lib directory. That would, arguably,
be safer. You could specify exactly which files to copy and, for extra
security if required, validate the JAR signature (if signed) or SHA512
hash, etc. before copying. To be honest, I'm struggling to think of a
scenario where this would be necessary.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org



[OT] Re: Question about DirResourceSet?

2019-10-14 Thread tomcat

From a long-time (occasional) list contributor :
That's a nice post, in many ways, and a good way to get quick and useful 
answers.
I only regret that my own knowledge is not sufficient to provide such an answer.
(We regularly complain at people posting to this list, when their post is "not nice", so I 
thought we should also from time to time give kudos when it is).


On 14.10.2019 16:37, Robert Olofsson wrote:

Hi!

Some background:
We are currently running tomcat (9.0.26) and we serve data to
both html/webapp and to our java application. The java application
uses a lot of the same jar files that our servlets use.

We have had tomcat setup with two directories:
1) webapps//WEB-INF/lib (as usual for servlet classes)
2) webapps//clientdir/ (jar files for the java application).

This means that we have a lot of duplication of jar files in these two
directories.

We would like to have the duplicate files in only one place, sure
disk space is cheap, but data transfer takes time. We thought that
having the jars in the clientdir would be nice.

We have read the documentation for tomcat and found the resource handling
and it looks like we could possibly use something like:


   


We tested this lightly and things seems to work.

Questions:
Is there any problem with this?
If so, do you know of any better way to accomplish this?

Thanks
/robo


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org