On 23/04/2019 14:44, Christopher Schultz wrote:
> Mark,
> 
> On 4/18/19 14:34, ma...@apache.org wrote:
>> This is an automated email from the ASF dual-hosted git
>> repository.
> 
>> markt pushed a commit to branch master in repository
>> https://gitbox.apache.org/repos/asf/tomcat.git
> 
> 
>> The following commit(s) were added to refs/heads/master by this
>> push: new 3032e08  Security hardening. Avoid loading user specified
>> classes. 3032e08 is described below
> 
>> commit 3032e08baec63874fec292daf288c319719dfeac Author: Mark Thomas
>> <ma...@apache.org> AuthorDate: Thu Apr 18 19:32:57 2019 +0100
> 
>> Security hardening. Avoid loading user specified classes.
> 
>> The user is trusted so loading a user specified class should be
>> safe but given it isn't necessary to load the class, avoid doing
>> so. Reported by Coverity scan.
> 
> [...]
> 
>> diff --git a/java/org/apache/tomcat/util/IntrospectionUtils.java
>> b/java/org/apache/tomcat/util/IntrospectionUtils.java index
>> 82752e4..bb954fb 100644 ---
>> a/java/org/apache/tomcat/util/IntrospectionUtils.java +++
>> b/java/org/apache/tomcat/util/IntrospectionUtils.java @@ -433,6
>> +433,28 @@ public final class IntrospectionUtils { return result; 
>> }
> 
>> + +    public static boolean isInstance(Class<?> clazz, String
>> type) { +        if (type.equals(clazz.getName())) { +
>> return true; +        } + +        Class<?>[] ifaces =
>> clazz.getInterfaces(); +        for (Class<?> iface : ifaces) { +
>> if (isInstance(iface, type)) { +                return true; +
>> } +        } + +        Class<?> superClazz =
>> clazz.getSuperclass(); +        if (superClazz == null) { +
>> return false; +        } else { +            return
>> isInstance(superClazz, type); +        } +    } +
> 
> This method is basically Class.isAssignableFrom except that it works
> on a String argument and never instantiates the Class object it
> represents, right?

Correct.

> If so, I'll add a little Javadoc because when I has read the code
> (without apparently reading the "Detail" text of this patch), I
> thought "why not just call Class.isAssignableFrom instead of all this?

Thanks.


> Is there ever any problem with primitive values, or is that never an
> issue?

In this instance I think any primitive type will be boxed to the
corresponding object. More generally, I guess this might get used with
primitives at some point. I don't think I tested that.

Mark

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

Reply via email to