Well, before even starting down this rabbit hole, it seems like the first question one should ask is what problems do you see reflection solving, that aren't readily solvable by current language mechanisms.
Ultimately, reflection-based programs largely seem like poorly specified, bug-ridden type functions. Sandro On 04/04/2014 1:55 PM, Jonathan S. Shapiro wrote: > One of the (many) issues that I don't understand in modern language > APIs is the impact of the reflection and introspection APIs. I am > aware that they create a number of security issues as well as a number > of issues for bytecode VM implementations. I'm not sure whether these > issues are "real" issues or whether they arise from a fundamental > failure to understand what protections are possible. > > It seems to me that the following statements are true: > > * If a program has read access to the files that comprise its > constituent class libraries, then it has the ability to *read* all > of its initial code and data, without regard to any protection > mechanisms that may exist in the language (private/protected) or > the libraries (e.g. security APIs that rely on stack introspection). > * The reflection API extends this to /runtime/ data. The ability to > read runtime data raises a range of security issues, at the very > least because runtime data may be privileged state. > * Finally, the reflection API permits mutation of the heap, after > which a lot of security and even durability assumptions go out the > window. > > Here are my questions, though: > > 1. How many of these issues exist because Java class loader mechanism > wasn't designed correctly at the beginning? We shouldn't confuse > design errors for unresolvable security problems. > > 2. How many of the perceived problems exist because reflection makes > it really hard to build a plausible SecurityManager? And given that > the SecurityManager notion in Java is mostly broken, how much should > we care? > > > My question may inadvertently get mired in a discussion of security > models. The Java model (and the .NET model) in my mind just doesn't > work. Part of the reason for asking this question is that I'm > considering what the security model in the BitC runtime should look > like, so I want to know how other systems and languages have boogered > such things. :-) > > > shap > > > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
