db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: [Fwd: Re: derbynet/getCurrentProperties.java fails]
Date Mon, 17 Oct 2005 22:25:53 GMT
Deepa Remesh wrote:

> On 10/17/05, Daniel John Debrunner <djd@debrunners.com> wrote:
> 
> 
>>OK, I see now that this is because you fixed DERBY-613 as part of
>>DERBY-375 (see Kathey's comment in DERBY-375).
>>
>>This means you need to modify the permissions already granted to
>>derbynet.jar, not add new ones. Here's the extract from the policy file
>>for the network server tracing.
>>
>>  // tracing files - BUG DERBY-613 default location for tracing
>>  // file is meant to be ${derby.system.home} but instead is ${user.dir}
>>  // Changes DERBY-613 may require modifying this permission.
>>  permission java.io.FilePermission "${user.dir}${/}*", "write";
>>
>>I think you need to change that to something like
>>
>>  // tracing files, default to derby.system.home
>>  permission java.io.FilePermission "${derby.system.home}${/}*", "write";
>>
> 
> 
> I kept the permission for ${user.dir} because if derby.system.home is
> not set, the default trace directory will be ${user.dir}. Test harness
> always starts network server by setting derby.system.home. But if
> there are tests which start network server as internal process and do
> not set derby.system.home (like derbynet/testProperties.java),
> ${user.dir} will be used for tracing.

If the permission is not required to run the tests then it must not be
in the policy file. Otherwise it increases the chance that the
permission is being used for some other incorrect purpose by the engine
or network server (etc.) and thus allows bugs to be hidden.

If some future test needs network tracing and doesn't set
derby.system.home then a much safer approach is for that test to set an
explicit tracing directory and have write permission on that directory.

A permission such as this is much less likely to hide bugs than the
second more general version

// very specific permission, less likely to be abused accidentally
permission java.io.FilePermission
"${user.dir}${/}testPropertiesTraceFiles${/}*", "write";

// very generic permission, lots of potential to be used accidentally.
permission java.io.FilePermission "${user.dir}${/}*", "write";

In the future I would like to re-work the current permissions to be more
specific, e.g. ensure all test databases are in
${derby.system.home}/db/, this would separate out the permissions used
and needed  by the engine from the permssions used by the network server.

Dan.



Mime
View raw message