On 16.09.10 19:02, Myrna van Lunteren wrote:
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?
Hi Myrna,
I think it's obvious enough - don't make testing/debug code accessible
in a production environment.
We already have file methods in there that are public static, but none
of them delete files. If you fire off what I call "persistent recursive
delete", it will try to delete all files in the specified path and it
will not stop until it has tried to delete every single file and
directory in the specified path. Of course, it's no more dangerous than
writing 'rm -Rf <some-path>', except that the visibility is poorer. So,
during testing, you do not want to point the method at your home
directory and run without a security manager...
I'll see if I can add some kind of safeguard to isolate the method to
the base test directory - the test framework should limit its file
activities to that directory in any case. This will reduce the chances
of causing havoc for an unfortunate Derby developer running with a
misconfigured or no security manager.
I logged DERBY-4804 to track the work.
@Knut
Yes, that's the reason why I ask - and I do feel I'm being rather
cautious in this case :)
Thanks,
--
Kristian
Myrna
