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