Myrna van Lunteren wrote:
On 10/25/06, Kristian Waagan <[EMAIL PROTECTED]> wrote:
Hello,
I was running various JUnit tests/suites and the test
'jdbcapi.BlobClob4Blob' was failing with a security exception, but when
run as part of 'suites.All' it was not.
After some investigation, I discovered the following:
1) derby.system.home was set to a non-existing directory.
Set to `pwd`/system, see static initializer in TestConfiguration
2) When I ran the All suite, no security manager was installed.
I have not confirmed if this is true for all tests (it is probably
not), but no security manager was installed at the time when the
first setUp-method was run. I created DERBY-2000 to track this, and
also added a little more info.
Because of 2), creating derby.system.home worked when running the All
suite, but not when running the other test. What happens, is that the
directory is attempted created in 'impl.services.monitor.FileMonitor' if
it does not exists. When a SecurityException is raised, the
initialize-method returns false and the boot process is aborted. This
causes the line 'return getDriverModule().connect(...)' in
'jdbc.AutoloadedDriver' to throw a NPE (and this is what you get to see
when running the test).
I can think of two solutions to the directory creation problem:
a) Add write permissions to derby.system.home for derby.jar.
If this is done, the system would be able to create the directory,
and possibly overwrite derby.system.home if it happens to point to
a file (combination of user error and malicious/bad code in Derby),
but not delete it;
permission java.io.FilePermission "${derby.system.home}", "read,
write";
With the permission above, no permissions need to be granted to the
parent directory of derby.system.home.
b) Document that derby.system.home must point to an existing
directory when running JUnit tests.
I think a) seems most useful, especially in terms of user-friendliness.
On the other hand, you should know up front where the database store the
data, so option b) is not a disaster either.
Any opinions/questions?
--
Kristian
Can't we put a stop in somewhere(where?), i.e. bail out if system.home
does not exist or is a file (rather than a directory)?
Yes, we could do that, but is it what we want to happen?
Basically, it is what happens today, you just get a nicer error message.
The question then is whether we want the stop to happen in Derby
(FileMonitor?), or in the test system. For deployment, it makes it
easier to allow Derby to create derby.system.home if it has the
permissions to do so and the path is indeed a directory.
I tried specifying derby.system.home as a file with Derby 10.2.1.7, and
the error message you get in ij is "No suitable driver" (because the
engine is never booted and the driver not registered).
If nobody has strong opinions, I'm thinking about writing a patch to
improve the error handling and that still creates the directory if it is
valid and allowed.
--
Kristian
Myrna
