On Thu, Sep 16, 2010 at 8:33 AM, Knut Anders Hatlen <[email protected]> wrote: > Bryan Pendleton <[email protected]> writes: > >>> Since the comment in DERBY-3837 says the purpose of the test is to test >>> operation on read-only media, do you agree that we should make the >>> database directory truly read-only? >> >> +1. >> >> Thanks for tracking this down, and for the detailed description. Very >> interesting! > > I agree. Having a database that's partly read-only and partly writable > doesn't sound like a use case we would want to support, so +1 to making > the database in the test truly read-only. > >>> And while I'm at it, I might want to move some of the file-system >>> helper methods into PrivilegedFileOpsForTests. The motivating factor >>> is that when a removal of a directory fails (recursive delete), it may >>> be useful to see which files couldn't be deleted. The question is if >>> it is okay to add a public static persistent recursive delete method >>> running in a privileged block to the test code? > > You're asking because it's considered bad security practise to have > public helper methods doing privileged operations, right? If I > understand correctly, it will only be a security risk if someone runs > their production server with derbyTesting.jar in the classpath and has > granted delete permissions to derbyTesting.jar. I don't think that's > something we need to be concerned with in the test code. > > -- > Knut Anders >
I agree also to making the db fully read-only. Thanks for the analysis! I thought it would be obvious that derbyTesting.jar has no place in a production system...If you make this change to the helper method, do we need to document somewhere that the derbyTesting.jar opens up security issues or would it be obvious enough? Myrna
