Rick Hillegas <[EMAIL PROTECTED]> writes: I'll admit I am torn about this one. Just summarizing how I understand it at this point, I don't have a firm opinion.
Cons: - Changes default behavior (previous Derby versions did not come up with a default security manager; there was none). Can trip up exisiting applications, even after deployment time if testing is weak(?) - The errors we have seen may indicate the there are other "corners" lurking which could trip up some users. - If the application needs additional permissions, it can be annoying for many users not concerned about security, until they find out about the flag to switch the manager off. Pros: - The existence of a default policy file is a step ahead making it easier to protect against SQL injection attacks. - Secure-by-default: If the security "just there" the user will be more likely to use it, than if it takes a separate step to enable it. On the other hand, that step now is as simple as setting a flag (contrary to earlier version of Derby, where one would need to craft one's owen policy file). - Even any hassles have a (potential) upside: They direct attention towards an attack vector the naive user may not have considered. So the existence of a default policy file which is available easily is a Good Thing. Whether it is correct to have it set by default, is arguable. If you pressured me, I'd probably recommend against it at this point in my understanding. I *think* I would prefer a warning if no security manager was enabled. It still behooves the app writer to secure his apps against arbitrary SQL injection, too. Technically, the current flag -noSecurityManager could be augmented with a -securityManager flag to get the current behavior? -noSecurityManager would then just be redundant. In the final analysis it comes down to what annoys the Derby user more, a potentially unsafe system or the hassle of dealing with security. No free lunch... Thanks, Dag
