RE: Unable to access Global JNDI Resource

[Chinoy Gupta]

Ok. Thanks a lot Mark. 

Regards,
Chinoy

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Tuesday, October 04, 2016 2:37 PM
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Unable to access Global JNDI Resource

On 04/10/2016 09:33, Chinoy Gupta wrote:
> Hi Mark,
> 
> I verified with the changes you made and it is working now. Thanks a lot. Is 
> there any plan for next release in near future?

I typically do releases monthly, starting the release process at the beginning 
of the month. I like to clear all the open bugs first so exactly when the 
release starts depends on how long that takes.
Hopefully, I should be in a position to tag and start the actual release later 
this week.

Mark


> 
> Regards,
> Chinoy
> 
> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org]
> Sent: Tuesday, October 04, 2016 12:27 PM
> To: Tomcat Users List <users@tomcat.apache.org>
> Subject: Re: Unable to access Global JNDI Resource
> 
> On 04/10/2016 04:54, Chinoy Gupta wrote:
>> Hi Mark,
>>
>> Thanks for the info. But I am afraid the custom loader directly 
>> extends URLClassLoader. Actually my application is a generic web app 
>> which can be deployed in any ApplciationServer like tomcat, JBoss, 
>> etc. So I don't have any tomcat specific implementations.
> 
> That is fine. It isn't the class hierarchy that matters, but the class loader 
> hierarchy.
> 
> I've made the fix to 9.0.x, 8.5.x, 8.0.x, 7.0.x and 6.0.x.
> 
> As long as when you call getParent() recursively on your class loader the web 
> application class loader is returned before null is returned then it will now 
> work.
> 
> Mark
> 
> 
>>
>> Regards, Chinoy
>>
>> -Original Message- From: Mark Thomas 
>> [mailto:ma...@apache.org]
>> Sent: Monday, October 03, 2016 6:16 PM To:
>> Tomcat Users List <users@tomcat.apache.org> Subject: Re: Unable to 
>> access Global JNDI Resource
>>
>> On 30/09/2016 13:34, Chinoy Gupta wrote:
>>> Hi Mark,
>>>
>>> The following is added in server.xml:
>>>
>>>   >> name="UserDatabase" auth="Container"
>>> type="org.apache.catalina.UserDatabase" description="User database 
>>> that can be updated and saved"
>>> factory="org.apache.catalina.users.MemoryUserDatabaseFactory" 
>>> pathname="conf/tomcat-users.xml" />
>>>
>>> >> type="java.lang.String"/> 
>>>
>>> And the following is added in context.xml:
>>>
>>> >> type="java.lang.String" override="false"/> >> name="my/secret/password" global="my/secret/password"
>>> type="java.lang.String" />
>>>
>>> If I try to get "my/local/test", it works and I get "local test".
>>> But if I try to get " my/secret/password", it returns NULL.
>>
>> This works for me with both 9.0.x and 8.0.x.
>>
>> Your previous posts mentioned a custom class loader. If the web 
>> application class loader is not the thread context class loader then 
>> the resource will not be visible.
>>
>> Is that custom class loader a child of the web application class 
>> loader? If so, a fix for the next release should be fairly simple.
>>
>> Mark
>>
>>
>>>
>>> Regards, Chinoy
>>>
>>> -Original Message- From: Mark Thomas 
>>> [mailto:ma...@apache.org] Sent: Friday, September 30, 2016 6:00 PM
>>> To: Tomcat Users List <users@tomcat.apache.org> Subject: Re: Unable 
>>> to access Global JNDI Resource
>>>
>>> On 30/09/2016 13:20, Chinoy Gupta wrote:
>>>> Hi Mark,
>>>>
>>>> This is my stacktrace:
>>>>
>>>> ResourceLinkFactory.validateGlobalResourceAccess(String) line:
>>>> 109 ResourceLinkFactory.getObjectInstance(Object, Name, Context,
>>>> Hashtable) line: 142 NamingManager.getObjectInstance(Object,
>>>> Name, Context, Hashtable) line: 321 NamingContext.lookup(Name,
>>>> boolean) line: 847
>>>> NamingContext.lookup(Name) line: 158 NamingContext.lookup(Name,
>>>> boolean) line: 835 NamingContext.lookup(Name) line: 158 
>>>> NamingContext.lookup(Name, boolean) line: 835
>>>> NamingContext.lookup(String) line: 172
>>>>
>>>> validateGlobalResourceAccess function returns false and then 
>>>> getObjectInstance returns NULL.
>>>
>>> You haven't defi

RE: Unable to access Global JNDI Resource

[Chinoy Gupta]

Hi Mark,

I verified with the changes you made and it is working now. Thanks a lot. Is 
there any plan for next release in near future?

Regards,
Chinoy

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Tuesday, October 04, 2016 12:27 PM
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Unable to access Global JNDI Resource

On 04/10/2016 04:54, Chinoy Gupta wrote:
> Hi Mark,
> 
> Thanks for the info. But I am afraid the custom loader directly 
> extends URLClassLoader. Actually my application is a generic web app 
> which can be deployed in any ApplciationServer like tomcat, JBoss, 
> etc. So I don't have any tomcat specific implementations.

That is fine. It isn't the class hierarchy that matters, but the class loader 
hierarchy.

I've made the fix to 9.0.x, 8.5.x, 8.0.x, 7.0.x and 6.0.x.

As long as when you call getParent() recursively on your class loader the web 
application class loader is returned before null is returned then it will now 
work.

Mark


> 
> Regards, Chinoy
> 
> -Original Message- From: Mark Thomas [mailto:ma...@apache.org] 
> Sent: Monday, October 03, 2016 6:16 PM To:
> Tomcat Users List <users@tomcat.apache.org> Subject: Re: Unable to 
> access Global JNDI Resource
> 
> On 30/09/2016 13:34, Chinoy Gupta wrote:
>> Hi Mark,
>> 
>> The following is added in server.xml:
>> 
>>   > name="UserDatabase" auth="Container"
>> type="org.apache.catalina.UserDatabase" description="User database 
>> that can be updated and saved"
>> factory="org.apache.catalina.users.MemoryUserDatabaseFactory" 
>> pathname="conf/tomcat-users.xml" />
>> 
>> > type="java.lang.String"/> 
>> 
>> And the following is added in context.xml:
>> 
>> > type="java.lang.String" override="false"/> > name="my/secret/password" global="my/secret/password"
>> type="java.lang.String" />
>> 
>> If I try to get "my/local/test", it works and I get "local test".
>> But if I try to get " my/secret/password", it returns NULL.
> 
> This works for me with both 9.0.x and 8.0.x.
> 
> Your previous posts mentioned a custom class loader. If the web 
> application class loader is not the thread context class loader then 
> the resource will not be visible.
> 
> Is that custom class loader a child of the web application class 
> loader? If so, a fix for the next release should be fairly simple.
> 
> Mark
> 
> 
>> 
>> Regards, Chinoy
>> 
>> -Original Message- From: Mark Thomas 
>> [mailto:ma...@apache.org] Sent: Friday, September 30, 2016 6:00 PM
>> To: Tomcat Users List <users@tomcat.apache.org> Subject: Re: Unable 
>> to access Global JNDI Resource
>> 
>> On 30/09/2016 13:20, Chinoy Gupta wrote:
>>> Hi Mark,
>>> 
>>> This is my stacktrace:
>>> 
>>> ResourceLinkFactory.validateGlobalResourceAccess(String) line:
>>> 109 ResourceLinkFactory.getObjectInstance(Object, Name, Context,
>>> Hashtable) line: 142 NamingManager.getObjectInstance(Object,
>>> Name, Context, Hashtable) line: 321 NamingContext.lookup(Name, 
>>> boolean) line: 847
>>> NamingContext.lookup(Name) line: 158 NamingContext.lookup(Name,
>>> boolean) line: 835 NamingContext.lookup(Name) line: 158 
>>> NamingContext.lookup(Name, boolean) line: 835
>>> NamingContext.lookup(String) line: 172
>>> 
>>> validateGlobalResourceAccess function returns false and then 
>>> getObjectInstance returns NULL.
>> 
>> You haven't defined a ResourceLink.
>> 
>> Mark
>> 
>>> 
>>> Regards, Chinoy
>>> 
>>> 
>>> -Original Message- From: Mark Thomas 
>>> [mailto:ma...@apache.org] Sent: Friday, September 30, 2016 5:28 PM 
>>> To: Tomcat Users List <users@tomcat.apache.org> Subject: Re:
>>> Unable to access Global JNDI Resource
>>> 
>>> On 30/09/2016 12:50, Chinoy Gupta wrote:
>>>> I am getting NULL instead of the resource's value. I debugged the 
>>>> tomcat code and figured out that in ResourceLinkFactory.java, 
>>>> before fetching the resource there is a validation based on current 
>>>> classloader. That validation fails and tomcat returns NULL.
>>> 
>>> The above statement is not correct. If the class loader based 
>>> validation fails, Tomcat throws an exception. It does not return 
>>> null.
>>> 
>>> Mark
>>> 
>>>

RE: Unable to access Global JNDI Resource

[Chinoy Gupta]

Hi Mark,

Thanks for the info. But I am afraid the custom loader directly extends 
URLClassLoader. Actually my application is a generic web app which can be 
deployed in any ApplciationServer like tomcat, JBoss, etc. So I don't have any 
tomcat specific implementations.

Regards,
Chinoy

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Monday, October 03, 2016 6:16 PM
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Unable to access Global JNDI Resource

On 30/09/2016 13:34, Chinoy Gupta wrote:
> Hi Mark,
> 
> The following is added in server.xml:
> 
>  
> 
>type="org.apache.catalina.UserDatabase"
>   description="User database that can be updated and saved"
>   factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
>   pathname="conf/tomcat-users.xml" />
> 
>type="java.lang.String"/>
>   
> 
> And the following is added in context.xml:
> 
>type="java.lang.String" override="false"/>
>type="java.lang.String" />
> 
> If I try to get "my/local/test", it works and I get "local test". But if I 
> try to get " my/secret/password", it returns NULL.

This works for me with both 9.0.x and 8.0.x.

Your previous posts mentioned a custom class loader. If the web application 
class loader is not the thread context class loader then the resource will not 
be visible.

Is that custom class loader a child of the web application class loader?
If so, a fix for the next release should be fairly simple.

Mark


> 
> Regards,
> Chinoy
> 
> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org]
> Sent: Friday, September 30, 2016 6:00 PM
> To: Tomcat Users List <users@tomcat.apache.org>
> Subject: Re: Unable to access Global JNDI Resource
> 
> On 30/09/2016 13:20, Chinoy Gupta wrote:
>> Hi Mark,
>>
>> This is my stacktrace:
>>
>>  ResourceLinkFactory.validateGlobalResourceAccess(String) line: 109  
>>  ResourceLinkFactory.getObjectInstance(Object, Name, Context, 
>> Hashtable) line: 142  
>>  NamingManager.getObjectInstance(Object, Name, Context, Hashtable) 
>> line: 321
>>  NamingContext.lookup(Name, boolean) line: 847   
>>  NamingContext.lookup(Name) line: 158
>>  NamingContext.lookup(Name, boolean) line: 835   
>>  NamingContext.lookup(Name) line: 158
>>  NamingContext.lookup(Name, boolean) line: 835   
>>  NamingContext.lookup(String) line: 172
>>
>> validateGlobalResourceAccess function returns false and then 
>> getObjectInstance returns NULL.
> 
> You haven't defined a ResourceLink.
> 
> Mark
> 
>>
>> Regards,
>> Chinoy
>>
>>
>> -Original Message-
>> From: Mark Thomas [mailto:ma...@apache.org]
>> Sent: Friday, September 30, 2016 5:28 PM
>> To: Tomcat Users List <users@tomcat.apache.org>
>> Subject: Re: Unable to access Global JNDI Resource
>>
>> On 30/09/2016 12:50, Chinoy Gupta wrote:
>>> I am getting NULL instead of the resource's value. I debugged the 
>>> tomcat code and figured out that in ResourceLinkFactory.java, before 
>>> fetching the resource there is a validation based on current 
>>> classloader. That validation fails and tomcat returns NULL.
>>
>> The above statement is not correct. If the class loader based validation 
>> fails, Tomcat throws an exception. It does not return null.
>>
>> Mark
>>
>>>
>>> -Original Message- From: Mark Thomas 
>>> [mailto:ma...@apache.org]
>>> Sent: Friday, September 30, 2016 4:11 PM
>>> To: Tomcat Users List <users@tomcat.apache.org> Subject: Re: Unable 
>>> to access Global JNDI Resource
>>>
>>> On 30/09/2016 11:30, Chinoy Gupta wrote:
>>>> Hi,
>>>>
>>>> I have a web application which runs on tomcat. In server.xml, I 
>>>> provide some resources under " section" and 
>>>> then provide a ResourceLink to the same in context.xml. And then I 
>>>> fetch that resource in my application. This was working properly 
>>>> earlier but started breaking with 8.0.37.
>>>
>>> Define breaking. Ideally with a stack trace.
>>>
>>> Mark
>>>
>>>
>>>> I think the reason is the extra validation check introduced in 
>>>> ResourceLinkFactory class. My application has its own classlo

RE: Unable to access Global JNDI Resource

[Chinoy Gupta]

Also if I comment the following lines, from ResourceLinkFactory.java and 
rebuild tomcat, it starts working:

   if (!validateGlobalResourceAccess(globalName)) {
return null;
}

Clearly it was introduced to make sure that only authorized apps can access 
that resource. My question is how can I make sure that my application is 
authorized?

Regards,
Chinoy

-Original Message-
From: Chinoy Gupta [mailto:cgu...@adobe.com] 
Sent: Friday, September 30, 2016 9:54 PM
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Unable to access Global JNDI Resource

But the same thing is working in 8.0.36.

Regards,
Chinoy



On Fri, Sep 30, 2016 at 9:33 PM +0530, "Christopher Schultz" 
<ch...@christopherschultz.net<mailto:ch...@christopherschultz.net>> wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Chinoy,

On 9/30/16 8:34 AM, Chinoy Gupta wrote:
> Hi Mark,
>
> The following is added in server.xml:
>
>name="UserDatabase" auth="Container"
> type="org.apache.catalina.UserDatabase" description="User database 
> that can be updated and saved"
> factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
> pathname="conf/tomcat-users.xml" />
>
>  type="java.lang.String"/> 
>
> And the following is added in context.xml:
>
>  type="java.lang.String" override="false"/>  name="my/secret/password" global="my/secret/password"
> type="java.lang.String" />
>
> If I try to get "my/local/test", it works and I get "local test".
> But if I try to get " my/secret/password", it returns NULL.

You aren't mapping it correctly.

Please have another look at the documentation for .

- -chris

> -Original Message- From: Mark Thomas [mailto:ma...@apache.org] 
> Sent: Friday, September 30, 2016 6:00 PM
> To: Tomcat Users List <users@tomcat.apache.org> Subject: Re: Unable to 
> access Global JNDI Resource
>
> On 30/09/2016 13:20, Chinoy Gupta wrote:
>> Hi Mark,
>>
>> This is my stacktrace:
>>
>> ResourceLinkFactory.validateGlobalResourceAccess(String) line:
>> 109 ResourceLinkFactory.getObjectInstance(Object, Name, Context,
>> Hashtable) line: 142 NamingManager.getObjectInstance(Object,
>> Name, Context, Hashtable) line: 321 NamingContext.lookup(Name, 
>> boolean) line: 847
>> NamingContext.lookup(Name) line: 158 NamingContext.lookup(Name,
>> boolean) line: 835 NamingContext.lookup(Name) line: 158 
>> NamingContext.lookup(Name, boolean) line: 835
>> NamingContext.lookup(String) line: 172
>>
>> validateGlobalResourceAccess function returns false and then 
>> getObjectInstance returns NULL.
>
> You haven't defined a ResourceLink.
>
> Mark
>
>>
>> Regards, Chinoy
>>
>>
>> -Original Message- From: Mark Thomas 
>> [mailto:ma...@apache.org] Sent: Friday, September 30, 2016 5:28 PM 
>> To: Tomcat Users List <users@tomcat.apache.org> Subject: Re:
>> Unable to access Global JNDI Resource
>>
>> On 30/09/2016 12:50, Chinoy Gupta wrote:
>>> I am getting NULL instead of the resource's value. I debugged the 
>>> tomcat code and figured out that in ResourceLinkFactory.java, before 
>>> fetching the resource there is a validation based on current 
>>> classloader. That validation fails and tomcat returns NULL.
>>
>> The above statement is not correct. If the class loader based 
>> validation fails, Tomcat throws an exception. It does not return 
>> null.
>>
>> Mark
>>
>>>
>>> -Original Message- From: Mark Thomas 
>>> [mailto:ma...@apache.org] Sent: Friday, September 30, 2016 4:11 PM 
>>> To: Tomcat Users List <users@tomcat.apache.org> Subject: Re:
>>> Unable to access Global JNDI Resource
>>>
>>> On 30/09/2016 11:30, Chinoy Gupta wrote:
>>>> Hi,
>>>>
>>>> I have a web application which runs on tomcat. In server.xml, I 
>>>> provide some resources under " section" and 
>>>> then provide a ResourceLink to the same in context.xml. And then I 
>>>> fetch that resource in my application. This was working properly 
>>>> earlier but started breaking with 8.0.37.
>>>
>>> Define breaking. Ideally with a stack trace.
>>>
>>> Mark
>>>
>>>
>>>> I think the reason is the extra validation check introduced in 
>>>> ResourceLinkFactory class. My application has its o

Re: Unable to access Global JNDI Resource

[Chinoy Gupta]

But the same thing is working in 8.0.36.

Regards,
Chinoy



On Fri, Sep 30, 2016 at 9:33 PM +0530, "Christopher Schultz" 
<ch...@christopherschultz.net<mailto:ch...@christopherschultz.net>> wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Chinoy,

On 9/30/16 8:34 AM, Chinoy Gupta wrote:
> Hi Mark,
>
> The following is added in server.xml:
>
>name="UserDatabase" auth="Container"
> type="org.apache.catalina.UserDatabase" description="User database
> that can be updated and saved"
> factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
> pathname="conf/tomcat-users.xml" />
>
>  type="java.lang.String"/> 
>
> And the following is added in context.xml:
>
>  type="java.lang.String" override="false"/>  name="my/secret/password" global="my/secret/password"
> type="java.lang.String" />
>
> If I try to get "my/local/test", it works and I get "local test".
> But if I try to get " my/secret/password", it returns NULL.

You aren't mapping it correctly.

Please have another look at the documentation for .

- -chris

> -Original Message- From: Mark Thomas
> [mailto:ma...@apache.org] Sent: Friday, September 30, 2016 6:00 PM
> To: Tomcat Users List <users@tomcat.apache.org> Subject: Re: Unable
> to access Global JNDI Resource
>
> On 30/09/2016 13:20, Chinoy Gupta wrote:
>> Hi Mark,
>>
>> This is my stacktrace:
>>
>> ResourceLinkFactory.validateGlobalResourceAccess(String) line:
>> 109 ResourceLinkFactory.getObjectInstance(Object, Name, Context,
>> Hashtable) line: 142 NamingManager.getObjectInstance(Object,
>> Name, Context, Hashtable) line: 321
>> NamingContext.lookup(Name, boolean) line: 847
>> NamingContext.lookup(Name) line: 158 NamingContext.lookup(Name,
>> boolean) line: 835 NamingContext.lookup(Name) line: 158
>> NamingContext.lookup(Name, boolean) line: 835
>> NamingContext.lookup(String) line: 172
>>
>> validateGlobalResourceAccess function returns false and then
>> getObjectInstance returns NULL.
>
> You haven't defined a ResourceLink.
>
> Mark
>
>>
>> Regards, Chinoy
>>
>>
>> -Original Message- From: Mark Thomas
>> [mailto:ma...@apache.org] Sent: Friday, September 30, 2016 5:28
>> PM To: Tomcat Users List <users@tomcat.apache.org> Subject: Re:
>> Unable to access Global JNDI Resource
>>
>> On 30/09/2016 12:50, Chinoy Gupta wrote:
>>> I am getting NULL instead of the resource's value. I debugged
>>> the tomcat code and figured out that in
>>> ResourceLinkFactory.java, before fetching the resource there is
>>> a validation based on current classloader. That validation
>>> fails and tomcat returns NULL.
>>
>> The above statement is not correct. If the class loader based
>> validation fails, Tomcat throws an exception. It does not return
>> null.
>>
>> Mark
>>
>>>
>>> -Original Message- From: Mark Thomas
>>> [mailto:ma...@apache.org] Sent: Friday, September 30, 2016 4:11
>>> PM To: Tomcat Users List <users@tomcat.apache.org> Subject: Re:
>>> Unable to access Global JNDI Resource
>>>
>>> On 30/09/2016 11:30, Chinoy Gupta wrote:
>>>> Hi,
>>>>
>>>> I have a web application which runs on tomcat. In server.xml,
>>>> I provide some resources under "
>>>> section" and then provide a ResourceLink to the same in
>>>> context.xml. And then I fetch that resource in my
>>>> application. This was working properly earlier but started
>>>> breaking with 8.0.37.
>>>
>>> Define breaking. Ideally with a stack trace.
>>>
>>> Mark
>>>
>>>
>>>> I think the reason is the extra validation check introduced
>>>> in ResourceLinkFactory class. My application has its own
>>>> classloader and when I try to fetch the JNDI resource, the
>>>> Thread's classloader is my custom one rather than the default
>>>> one. Because of that validation fails and tomcat returns
>>>> NULL. Is there a way to fix this through configuration or any
>>>> other means?
>>>>
>>>> Regards, Chinoy
>>>>
>>>>
>>>
>>>
>>> 
- -
>>>
>>>
>>
>>>
To unsubscribe, e-mail: users-un

RE: Unable to access Global JNDI Resource

[Chinoy Gupta]

Hi Mark,

The following is added in server.xml:

 



  
  

And the following is added in context.xml:

  
  

If I try to get "my/local/test", it works and I get "local test". But if I try 
to get " my/secret/password", it returns NULL.

Regards,
Chinoy

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Friday, September 30, 2016 6:00 PM
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Unable to access Global JNDI Resource

On 30/09/2016 13:20, Chinoy Gupta wrote:
> Hi Mark,
> 
> This is my stacktrace:
> 
>   ResourceLinkFactory.validateGlobalResourceAccess(String) line: 109  
>   ResourceLinkFactory.getObjectInstance(Object, Name, Context, 
> Hashtable) line: 142  
>   NamingManager.getObjectInstance(Object, Name, Context, Hashtable) 
> line: 321
>   NamingContext.lookup(Name, boolean) line: 847   
>   NamingContext.lookup(Name) line: 158
>   NamingContext.lookup(Name, boolean) line: 835   
>   NamingContext.lookup(Name) line: 158
>   NamingContext.lookup(Name, boolean) line: 835   
>   NamingContext.lookup(String) line: 172
> 
> validateGlobalResourceAccess function returns false and then 
> getObjectInstance returns NULL.

You haven't defined a ResourceLink.

Mark

> 
> Regards,
> Chinoy
> 
> 
> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org]
> Sent: Friday, September 30, 2016 5:28 PM
> To: Tomcat Users List <users@tomcat.apache.org>
> Subject: Re: Unable to access Global JNDI Resource
> 
> On 30/09/2016 12:50, Chinoy Gupta wrote:
>> I am getting NULL instead of the resource's value. I debugged the 
>> tomcat code and figured out that in ResourceLinkFactory.java, before 
>> fetching the resource there is a validation based on current 
>> classloader. That validation fails and tomcat returns NULL.
> 
> The above statement is not correct. If the class loader based validation 
> fails, Tomcat throws an exception. It does not return null.
> 
> Mark
> 
>>
>> -Original Message- From: Mark Thomas 
>> [mailto:ma...@apache.org]
>> Sent: Friday, September 30, 2016 4:11 PM
>> To: Tomcat Users List <users@tomcat.apache.org> Subject: Re: Unable 
>> to access Global JNDI Resource
>>
>> On 30/09/2016 11:30, Chinoy Gupta wrote:
>>> Hi,
>>>
>>> I have a web application which runs on tomcat. In server.xml, I 
>>> provide some resources under " section" and 
>>> then provide a ResourceLink to the same in context.xml. And then I 
>>> fetch that resource in my application. This was working properly 
>>> earlier but started breaking with 8.0.37.
>>
>> Define breaking. Ideally with a stack trace.
>>
>> Mark
>>
>>
>>> I think the reason is the extra validation check introduced in 
>>> ResourceLinkFactory class. My application has its own classloader 
>>> and when I try to fetch the JNDI resource, the Thread's classloader 
>>> is my custom one rather than the default one. Because of that 
>>> validation fails and tomcat returns NULL. Is there a way to fix this 
>>> through configuration or any other means?
>>>
>>> Regards, Chinoy
>>>
>>>
>>
>>
>> -
>>
>>
> 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
>>
> 
> 
> -
> 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
> 


-
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

RE: Unable to access Global JNDI Resource

[Chinoy Gupta]

Hi Mark,

This is my stacktrace:

ResourceLinkFactory.validateGlobalResourceAccess(String) line: 109  
ResourceLinkFactory.getObjectInstance(Object, Name, Context, 
Hashtable) line: 142  
NamingManager.getObjectInstance(Object, Name, Context, Hashtable) 
line: 321
NamingContext.lookup(Name, boolean) line: 847   
NamingContext.lookup(Name) line: 158
NamingContext.lookup(Name, boolean) line: 835   
NamingContext.lookup(Name) line: 158
NamingContext.lookup(Name, boolean) line: 835   
NamingContext.lookup(String) line: 172

validateGlobalResourceAccess function returns false and then getObjectInstance 
returns NULL.

Regards,
Chinoy


-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Friday, September 30, 2016 5:28 PM
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Unable to access Global JNDI Resource

On 30/09/2016 12:50, Chinoy Gupta wrote:
> I am getting NULL instead of the resource's value. I debugged the 
> tomcat code and figured out that in ResourceLinkFactory.java, before 
> fetching the resource there is a validation based on current 
> classloader. That validation fails and tomcat returns NULL.

The above statement is not correct. If the class loader based validation fails, 
Tomcat throws an exception. It does not return null.

Mark

> 
> -Original Message- From: Mark Thomas [mailto:ma...@apache.org] 
> Sent: Friday, September 30, 2016 4:11 PM
> To: Tomcat Users List <users@tomcat.apache.org> Subject: Re: Unable to 
> access Global JNDI Resource
> 
> On 30/09/2016 11:30, Chinoy Gupta wrote:
>> Hi,
>> 
>> I have a web application which runs on tomcat. In server.xml, I 
>> provide some resources under " section" and  
>> then provide a ResourceLink to the same in context.xml. And then I  
>> fetch that resource in my application. This was working properly 
>> earlier but started breaking with 8.0.37.
> 
> Define breaking. Ideally with a stack trace.
> 
> Mark
> 
> 
>> I think the reason is the extra validation check introduced in 
>> ResourceLinkFactory class. My application has its own classloader and 
>> when I try to fetch the JNDI resource, the Thread's classloader is my 
>> custom one rather than the default one. Because of that validation 
>> fails and tomcat returns NULL. Is there a way to fix this through 
>> configuration or any other means?
>> 
>> Regards, Chinoy
>> 
>> 
> 
> 
> -
>
> 
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
> 


-
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

RE: Unable to access Global JNDI Resource

[Chinoy Gupta]

I am getting NULL instead of the resource's value. I debugged the tomcat code 
and figured out that in ResourceLinkFactory.java, before fetching the resource 
there is a validation based on current classloader. That validation fails and 
tomcat returns NULL.


-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Friday, September 30, 2016 4:11 PM
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Unable to access Global JNDI Resource

On 30/09/2016 11:30, Chinoy Gupta wrote:
> Hi,
> 
> I have a web application which runs on tomcat. In server.xml, I 
> provide some resources under " section" and 
> then provide a ResourceLink to the same in context.xml. And then I 
> fetch that resource in my application. This was working properly 
> earlier but started breaking with 8.0.37.

Define breaking. Ideally with a stack trace.

Mark


> I think the reason is the
> extra validation check introduced in ResourceLinkFactory class. My 
> application has its own classloader and when I try to fetch the JNDI 
> resource, the Thread's classloader is my custom one rather than the 
> default one. Because of that validation fails and tomcat returns NULL. 
> Is there a way to fix this through configuration or any other means?
> 
> Regards, Chinoy
> 
> 


-
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

Unable to access Global JNDI Resource

[Chinoy Gupta]

Hi,

I have a web application which runs on tomcat. In server.xml, I provide some 
resources under " section" and then provide a 
ResourceLink to the same in context.xml. And then I fetch that resource in my 
application. This was working properly earlier but started breaking with 
8.0.37. I think the reason is the extra validation check introduced in 
ResourceLinkFactory class. My application has its own classloader and when I 
try to fetch the JNDI resource, the Thread's classloader is my custom one 
rather than the default one. Because of that validation fails and tomcat 
returns NULL. Is there a way to fix this through configuration or any other 
means?

Regards,
Chinoy

RE: CVE-2016-3092: Apache Commons Fileupload information disclosure vulnerability

[Chinoy Gupta]

Thanks for the info Mark.

Regards,
Chinoy

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Wednesday, June 22, 2016 11:43 AM
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: CVE-2016-3092: Apache Commons Fileupload information disclosure 
vulnerability

On 22/06/2016 05:51, Chinoy Gupta wrote:
> What about 8.5.x branch? Is that also affected.

Yes. 8.5.0 to 8.5.2 are affected.

> And I am not able to see this update on Tomcat security page. Any reasons for 
> that?

Oversight. I'll get it added later today unless someone beats me to it.
I'll also send out a corrected, Tomcat specific announcement for this rather 
than the forwarded one from Apache Commons below which has a number of errors 
in the Tomcat version information:
- 8.5.x is not listed (8.5.0 to 8.5.2 are affected)
- 6.0.x is listed as affected when it is not
- 5.5.x and earlier are listed as may be affected when they are not

Mark


> 
> Regards,
> Chinoy
> 
> -Original Message-
> From: Mark Thomas [mailto:ma...@apache.org]
> Sent: Tuesday, June 21, 2016 3:23 PM
> To: users@tomcat.apache.org; d...@tomcat.apache.org; 
> annou...@tomcat.apache.org; annou...@apache.org; 
> secur...@tomcat.apache.org
> Subject: Fwd: CVE-2016-3092: Apache Commons Fileupload information 
> disclosure vulnerability
> 
> 
>  Original Message 
> From: Jochen Wiedmann <jochen.wiedm...@gmail.com>
> Sent: 21 June 2016 10:18:15 BST
> To: priv...@commons.apache.org, "secur...@apache.org" 
> <secur...@apache.org>, Tomcat Security List 
> <secur...@tomcat.apache.org>, annou...@apache.org, Apache Commons 
> Developers List <d...@commons.apache.org>
> Subject: CVE-2016-3092: Apache Commons Fileupload information 
> disclosure vulnerability
> 
> CVE-2016-3092: Apache Commons Fileupload information disclosure 
> vulnerability
> 
> Severity: Moderate
> 
> Vendor:
> The Apache Software Foundation
> 
> Versions Affected:
> Apache Commons Fileupload 1.3 to 1.3.1 Apache Commons Fileupload 1.2 
> to 1.2.2 The unsupported Apache Commons Fileupload 1.0.x, and 1.1.x 
> may also be affected.
> Apache Tomcat 9.x to 9.0.0M6
> Apache Tomcat 8.x to 8.0.35
> Apache Tomcat 7.x to 7.0.69
> Apache Tomcat 6.x
> Unsupported versions of Apache Tomcat, like 5.x may also be affected.
> Apache Struts 2.5.x, and previous versions, which are distributing Commons 
> FileUpload 1.3.1, or earlier versions.
> 
> Description:
> A malicious client can send file upload requests that cause the HTTP server 
> using the Apache Commons Fileupload library to become unresponsive, 
> preventing the server from servicing other requests.
> 
> This flaw is not exploitable beyond causing the code to loop expending CPU 
> resources.
> 
> 
> Mitigation:
> All users of Apache Commons Fileupload should upgrade to 1.3.2.
> All users of Apache Tomcat should upgrade to 9.0.0M8, 8.0.36, or 7.0.70, 
> respectively.
> All users of Apache Struts should replace the copy of Commons FileUpload 
> (which is distributed as part of Struts) with the fixed version 1.3.2.
> 
> Workaround:
> 
> System administrators should restrict the permitted maximum size of HTTP 
> request header values (For example, Apache Httpd provides a 
> LimitRequestFieldSize directive, and Apache Tomcat provides a 
> maxHttpHeaderSize attribute in their respective configuration files). A 
> maximum header value size of 2048 bytes would block all dangerous request.
> 
> Example:
> File upload requests contain a so-called boundary in the Content-Type header:
> 
> Content-Type: multipart/mixed;
>   boundary=gc0p4Jq0M2Yt08jU534c0p
> 
> The boundary may be chosen by the request sender. In the case of previous 
> versions of Apache Commons Fileupload the boundary becomes dangerous, if its 
> size is close to 4096 bytes.
> 
> Credit:
> TERASOLUNA Framework Development Team at the Software Engineering, Research 
> and Development Headquarter, for detecting this flaw, and reporting it to the 
> JPCERT/CC, Taki Uchiyama (JPCERT/CC Vulnerability Handling Team) reported 
> this problem to us.
> 
> References:
> https://commons.apache.org/proper/commons-fileupload/security.html
> 
> 
> 
> Note: Apache Tomcat 6.x and earlier are NOT affected.


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

RE: CVE-2016-3092: Apache Commons Fileupload information disclosure vulnerability

[Chinoy Gupta]

What about 8.5.x branch? Is that also affected. And I am not able to see this 
update on Tomcat security page. Any reasons for that?

Regards,
Chinoy

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Tuesday, June 21, 2016 3:23 PM
To: users@tomcat.apache.org; d...@tomcat.apache.org; 
annou...@tomcat.apache.org; annou...@apache.org; secur...@tomcat.apache.org
Subject: Fwd: CVE-2016-3092: Apache Commons Fileupload information disclosure 
vulnerability


 Original Message 
From: Jochen Wiedmann 
Sent: 21 June 2016 10:18:15 BST
To: priv...@commons.apache.org, "secur...@apache.org" , 
Tomcat Security List , annou...@apache.org, Apache 
Commons Developers List 
Subject: CVE-2016-3092: Apache Commons Fileupload information disclosure 
vulnerability

CVE-2016-3092: Apache Commons Fileupload information disclosure vulnerability

Severity: Moderate

Vendor:
The Apache Software Foundation

Versions Affected:
Apache Commons Fileupload 1.3 to 1.3.1
Apache Commons Fileupload 1.2 to 1.2.2
The unsupported Apache Commons Fileupload 1.0.x, and 1.1.x may also be affected.
Apache Tomcat 9.x to 9.0.0M6
Apache Tomcat 8.x to 8.0.35
Apache Tomcat 7.x to 7.0.69
Apache Tomcat 6.x
Unsupported versions of Apache Tomcat, like 5.x may also be affected.
Apache Struts 2.5.x, and previous versions, which are distributing Commons 
FileUpload 1.3.1, or earlier versions.

Description:
A malicious client can send file upload requests that cause the HTTP server 
using the Apache Commons Fileupload library to become unresponsive, preventing 
the server from servicing other requests.

This flaw is not exploitable beyond causing the code to loop expending CPU 
resources.


Mitigation:
All users of Apache Commons Fileupload should upgrade to 1.3.2.
All users of Apache Tomcat should upgrade to 9.0.0M8, 8.0.36, or 7.0.70, 
respectively.
All users of Apache Struts should replace the copy of Commons FileUpload (which 
is distributed as part of Struts) with the fixed version 1.3.2.

Workaround:

System administrators should restrict the permitted maximum size of HTTP 
request header values (For example, Apache Httpd provides a 
LimitRequestFieldSize directive, and Apache Tomcat provides a maxHttpHeaderSize 
attribute in their respective configuration files). A maximum header value size 
of 2048 bytes would block all dangerous request.

Example:
File upload requests contain a so-called boundary in the Content-Type header:

Content-Type: multipart/mixed;
  boundary=gc0p4Jq0M2Yt08jU534c0p

The boundary may be chosen by the request sender. In the case of previous 
versions of Apache Commons Fileupload the boundary becomes dangerous, if its 
size is close to 4096 bytes.

Credit:
TERASOLUNA Framework Development Team at the Software Engineering, Research and 
Development Headquarter, for detecting this flaw, and reporting it to the 
JPCERT/CC, Taki Uchiyama (JPCERT/CC Vulnerability Handling Team) reported this 
problem to us.

References:
https://commons.apache.org/proper/commons-fileupload/security.html

--
The next time you hear: "Don't reinvent the wheel!"

http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg

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


Note: Apache Tomcat 6.x and earlier are NOT affected.



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

Re: AW: Question concerning mod_jk Security Fix CVE-2014-8111

[Chinoy Gupta]

Chris,

Is the trunk stable?

Regards,
Chinoy
On Sat, Aug 08, 2015 at 5:42 pm, Christopher Schultz 
ch...@christopherschultz.netmailto:ch...@christopherschultz.net wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Chinoy,

On 8/5/15 4:39 AM, Chinoy Gupta wrote:
 When can we expect the release of JK 1.2.41 source code?

Well, you can get your hands on it right now: svn trunk is always
available.

Or you can wait for the vote to finish... I believe we have 3 votes to
release.

http://tomcat.markmail.org/thread/evury5r6rwcls5df

- -chris

 -Original Message- From: Mark Thomas
 [mailto:ma...@apache.org] Sent: Sunday, July 26, 2015 10:16 PM To:
 Tomcat Users List users@tomcat.apache.org Subject: Re: AW:
 Question concerning mod_jk Security Fix CVE-2014-8111

 On 20/07/2015 10:58, Kreuser, Peter wrote:

 snip/

 Hi Mark,

 I appreciate your open comment and that clarifies the lengthy
 wait. I trust that now the solution gets going and will be solved
 soonish.

 I'm in no position to criticize any wrongdoing on this CVE. I
 only hope to find a clearer communication on the tomcat-security
 sites in the future and if THAT is RedHat's fault, then please
 clean up the process with them.

 I've just updated the JK security page on the Tomcat web site.

 To be clear, keeping this page up to date is entire the
 responsibility of the Tomcat committers. We dropped the ball on
 this one. That said, I had hoped - much like I hoped with the
 release - that RedHat would have directed one of their employees
 who is a committer to do the update. When that didn't happen pretty
 much immediately, we (the Tomcat committers) should have done it.

 I've read through the release docs and I should be able to get a
 1.2.41 source release out. I'm planning on doing that next. Binary
 releases are going to have to wait for other folks to contribute
 them.

 Cheers,

 Mark

 Thank You. Best regards,

 Peter

 PS: is that the correct position to add my response?

 Yes, it was.

 -


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

-BEGIN PGP SIGNATURE-
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJVxfHfAAoJEBzwKT+lPKRYPy8P/jN1cMPMQNXF7HCL9x9VC2o0
MoQK05eZ1EKj/hdI94kxr1Zz9tfFkm3Ud2XgMLIwexTpSwuIfkMRh4QREHGuAojO
sCzufygPc6Yb8Tf+HNDCi6GEqJy1SGB3inM4glgKWxuDugh+f8Kl+ZOKFBkeHeYV
Tjo900rLdQotxHI+RzUK/74Jua/He8Dtlne4XFoiCfpmqfIzwRtNmWJ2N9gWYpCn
fcpbQ0S4Hqw7YH6gzutDSgWiT/vlftx/5ynX9ybgSSFqVLsGmIxoTJMSot8/Rv0R
BlumYGTMfvf+NhzwCJSPab3xzcQsdYp8ObucuQp4FfKzh2i2R1VuT+cxZcuG04aT
69pE61DY6QOZUz6n8gCpzEaNTIYSA13ktS7qQQN1L2ik0HwapLaAx+xaIP7h58B1
yS6Q2N8Lm2k5UOqIEO+Nev6ZwnYHLIb7rdllpJiia+4t9eLfFrMWE/It8Tg9WE7q
t+wi0YFZDV8iB4c/2IBSN2xEUBcasUzfj2M0QOPVkNblPVtKkH0C9tqzukPLXRG2
VMtgpZwk1QWAPTi3Ghl1aKzhgvjGvzrrFfsLgxQDz4blg8TAzxuV1hn6pMUQxnsd
luxCMprIXUt5IL2UJejGnqLKKWUkXCuC0anxV9yQTMGWNr9CZlVKVJYEALPUJOLC
u5RWsrWcctsQauIZJQg0
=GPIs
-END PGP SIGNATURE-

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

RE: AW: Question concerning mod_jk Security Fix CVE-2014-8111

[Chinoy Gupta]

Hi,

When can we expect the release of JK 1.2.41 source code?

Regards,
Chinoy

-Original Message-
From: Mark Thomas [mailto:ma...@apache.org] 
Sent: Sunday, July 26, 2015 10:16 PM
To: Tomcat Users List users@tomcat.apache.org
Subject: Re: AW: Question concerning mod_jk Security Fix CVE-2014-8111

On 20/07/2015 10:58, Kreuser, Peter wrote:

snip/

 Hi Mark,
 
 I appreciate your open comment and that clarifies the lengthy wait. I 
 trust that now the solution gets going and will be solved soonish.
 
 I'm in no position to criticize any wrongdoing on this CVE. I only 
 hope to find a clearer communication on the tomcat-security sites in 
 the future and if THAT is RedHat's fault, then please clean up the 
 process with them.

I've just updated the JK security page on the Tomcat web site.

To be clear, keeping this page up to date is entire the responsibility of the 
Tomcat committers. We dropped the ball on this one. That said, I had hoped - 
much like I hoped with the release - that RedHat would have directed one of 
their employees who is a committer to do the update.
When that didn't happen pretty much immediately, we (the Tomcat
committers) should have done it.

I've read through the release docs and I should be able to get a 1.2.41 source 
release out. I'm planning on doing that next. Binary releases are going to have 
to wait for other folks to contribute them.

Cheers,

Mark

 Thank You. Best regards,
 
 Peter
 
 PS: is that the correct position to add my response?

Yes, it was.

-
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