On 01/08/15 23:38, Florian Weimer wrote: > On 08/01/2015 10:57 AM, Andrew Haley wrote: > >> However, the security problems are great. I haven't heard any >> suggestion about how to expose this feature to user-created libraries >> without breaking Java security, and I suspect there may be none. > > Are the problems greater than those of general reflection after > setAccessible(true)?
No. Either blows a huge hole on the usual guarantees. > I don't think so. I think the main objection would be philosophical > (against adding yet more trapdoors). "philosophical" doesn't mean "unimportant" or "fussy", though: it goes to the very core of the way that Java is used and is intended to be used. > I respect that—but at the same > time, there does not seem to be a core technical requirement why a > suitable API with a proper permission check could not be added to > the JDK. We have ReflectionFactory already, and I suppose as long as there are security checks there's no strong security-related reason not to move that class into, say, java.lang.reflect. Having said that, there are real problems where parts of the VM "know" something about the structure of an object. For example, String instances always have a char[] attached, and HotSpot makes use of that fact. Violating such invariants may cause the VM to crash. I don't know that a list of such invariants exists. Perhaps that's not exactly a security worry, but it's surely a problem. Andrew.
