> You have to consider the software in the context it is intended to be > used.
Thank you for clarifying and illustrating those notions. We are in agreement about JEXL intended usage and where the responsibility lies wrt security choices. But even in its usage context, with authenticated users, whether you allow files to be created or read or processes to be created should carefully be pondered and reflect a functional necessity. Security guys will say that authenticated users can still have a nefarious intent so users should only be allowed to access and use what is required to perform their duties... > If an application developer was daft enough to expose > System.exec() functionality to untrusted users, it would be treated as > an application vulnerability, not as a Java issue. Considering how complex and complicated software can be, I know I've been daft (on occasion hopefully) by lack of knowledge. A more secure default would avoid the daft configuration error, the one where you don't even know you are making a bad choice because you don't know enough yet. The goal is that we make it harder to ignore JEXL security configuration and if you do, we try and prevent the obvious security holes. With no explicit security configuration, as-is, 'System.exit()' is callable; surely, a better default should be proposed. Henri --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
