You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Daniel John Debrunner <dj...@debrunners.com> on 2005/10/17 22:22:31 UTC
[Fwd: Re: derbynet/getCurrentProperties.java fails]
Deepa Remesh wrote:
> Thanks Ole for posting the files.
>
> I did not catch this problem when I ran tests because I was using
> trunk/classes to run tests. When I tried with jars, the tests failed
> on my machine too. On looking at derby_tests.policy, the policy for
> running with classes covered writes to derby.system.home directory.
> But for derbynet.jar, permission to write to derby.system.home was not
> in the policy. I have added that and now the test
> derbynet/getCurrentProperties.java passes with jars. I am attaching
> the patch for policy file with this mail. If there are any comments,
> please let me know. I will upload it to JIRA once tests finish.
Why does derbynet.jar need to write to ${derby.system.home}?
I'll add comments to the file that added permissions need comments as to
why they are added.
The policies granted to the classes directory is a super-set of the
permissions granted to the other jars, but that does not imply a
permission granted to the classes is applicable for a specific jar.
Dan.
Re: [Fwd: Re: derbynet/getCurrentProperties.java fails]
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Deepa Remesh wrote:
>>I have attached a patch for test policy file with this mail. Here is a
>>summary of the patch:
>>1. Removes the following permission from derbynet.jar and classes
>>directory. This is not required after the patch for DERBY-375.
>>permission java.io.FilePermission "${user.dir}${/}*", "write";
>>
>>2. Grants the following permission to derbynet.jar. This is required
>>since tracing file location now defaults to ${derby.system.home}. The
>>test derbynet/getCurrentProperties.java uses this.
>>// tracing files default to derby.system.home,
>>derbynet/getCurrentProperties.java
>>permission java.io.FilePermission "${derby.system.home}${/}*", "write";
>>
>>3. Grants the following permission to derbynet.jar and classes
>>directory. This is required by the test jdbcapi/secureUsers1.sql when
>>run using sane builds.
>>// sane=true, jdbcapi/secureUsers1.sql
>>permission java.io.FilePermission "${user.dir}${/}CloudLDAP.out", "write";
>>
>>Please look into this patch and commit if okay.
Committed, trunk revision 326289
Thanks,
Dan.
Re: [Fwd: Re: derbynet/getCurrentProperties.java fails]
Posted by Deepa Remesh <dr...@gmail.com>.
Sorry...missed the attachment with previous mail.
Deepa
On 10/18/05, Deepa Remesh <dr...@gmail.com> wrote:
> On 10/17/05, Daniel John Debrunner <dj...@debrunners.com> wrote:
> >
> > 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.
>
> Thanks Dan for explaining in detail.
>
> I did the following:
> 1. Removed write permission for ${user.dir} from derbynet.jar and
> classes directory.
> 2. Granted permission to derbynet.jar to write to ${derby.system.home}
>
> With these changes, I ran derbyall with sane jars. The test
> jdbcapi/secureUsers1.sql failed in derbynetmats and derbynetclientmats
> becasue it needs permission to write CloudLDAP.out to ${user.dir}. I
> added this permission to derbynet.jar and classes directory. After
> this change, I reran the test jdbcapi/secureUsers1.sql in all
> frameworks with both sane jars and classes. No failures.
>
> I have attached a patch for test policy file with this mail. Here is a
> summary of the patch:
> 1. Removes the following permission from derbynet.jar and classes
> directory. This is not required after the patch for DERBY-375.
> permission java.io.FilePermission "${user.dir}${/}*", "write";
>
> 2. Grants the following permission to derbynet.jar. This is required
> since tracing file location now defaults to ${derby.system.home}. The
> test derbynet/getCurrentProperties.java uses this.
> // tracing files default to derby.system.home,
> derbynet/getCurrentProperties.java
> permission java.io.FilePermission "${derby.system.home}${/}*", "write";
>
> 3. Grants the following permission to derbynet.jar and classes
> directory. This is required by the test jdbcapi/secureUsers1.sql when
> run using sane builds.
> // sane=true, jdbcapi/secureUsers1.sql
> permission java.io.FilePermission "${user.dir}${/}CloudLDAP.out", "write";
>
> Please look into this patch and commit if okay.
>
> Deepa
>
Re: [Fwd: Re: derbynet/getCurrentProperties.java fails]
Posted by Deepa Remesh <dr...@gmail.com>.
On 10/17/05, Daniel John Debrunner <dj...@debrunners.com> wrote:
>
> 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.
Thanks Dan for explaining in detail.
I did the following:
1. Removed write permission for ${user.dir} from derbynet.jar and
classes directory.
2. Granted permission to derbynet.jar to write to ${derby.system.home}
With these changes, I ran derbyall with sane jars. The test
jdbcapi/secureUsers1.sql failed in derbynetmats and derbynetclientmats
becasue it needs permission to write CloudLDAP.out to ${user.dir}. I
added this permission to derbynet.jar and classes directory. After
this change, I reran the test jdbcapi/secureUsers1.sql in all
frameworks with both sane jars and classes. No failures.
I have attached a patch for test policy file with this mail. Here is a
summary of the patch:
1. Removes the following permission from derbynet.jar and classes
directory. This is not required after the patch for DERBY-375.
permission java.io.FilePermission "${user.dir}${/}*", "write";
2. Grants the following permission to derbynet.jar. This is required
since tracing file location now defaults to ${derby.system.home}. The
test derbynet/getCurrentProperties.java uses this.
// tracing files default to derby.system.home,
derbynet/getCurrentProperties.java
permission java.io.FilePermission "${derby.system.home}${/}*", "write";
3. Grants the following permission to derbynet.jar and classes
directory. This is required by the test jdbcapi/secureUsers1.sql when
run using sane builds.
// sane=true, jdbcapi/secureUsers1.sql
permission java.io.FilePermission "${user.dir}${/}CloudLDAP.out", "write";
Please look into this patch and commit if okay.
Deepa
Re: [Fwd: Re: derbynet/getCurrentProperties.java fails]
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Deepa Remesh wrote:
> On 10/17/05, Daniel John Debrunner <dj...@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.
Re: [Fwd: Re: derbynet/getCurrentProperties.java fails]
Posted by Deepa Remesh <dr...@gmail.com>.
On 10/17/05, Daniel John Debrunner <dj...@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.
I have the following for derbynet.jar and classes directory:
//
// Permissions for the network server (derbynet.jar)
//
grant codeBase "${csinfo.codejar}derbynet.jar" {
permission java.net.SocketPermission "127.0.0.1", "accept";
permission java.net.SocketPermission "localhost", "accept";
permission java.net.SocketPermission "${csinfo.serverhost}", "accept";
permission java.net.SocketPermission "${csinfo.trustedhost}", "accept";
// tracing files - BUG DERBY-613, DERBY-375 If ${derby.system.home} is set
// default location for trace files will be ${derby.system.home}. If
it is not set,
// default location will be ${user dir}.
permission java.io.FilePermission "${user.dir}${/}*", "write";
permission java.io.FilePermission "${derby.system.home}${/}*", "write";
// BUG DERBY-622 derbynet/sysinfo.java
permission java.io.FilePermission "${csinfo.codedir}${/}*", "read";
// BUG DERBY-616 lang/wisconsin.sql & jdbcapi/maxfieldsize.java
permission java.io.FilePermission
"${derby.system.home}${/}wombat${/}tmp${/}-", "read, write, delete";
// BUG DERBY-623 - sane=true
permission java.util.PropertyPermission "derby.monitor.verbose", "read";
permission java.util.PropertyPermission "derby.debug.*", "read";
};
//
// super-set of the jar permissions for running out of the classes directory
//
grant codeBase "${csinfo.codeclasses}" {
permission java.util.PropertyPermission "derby.*", "read";
permission java.lang.RuntimePermission "createClassLoader";
permission java.io.FilePermission
"${derby.system.home}${/}derby.properties", "read";
permission java.io.FilePermission
"${derby.system.home}${/}derby.log", "read, write, delete";
permission java.io.FilePermission "${derby.system.home}", "read";
permission java.io.FilePermission "${derby.system.home}${/}-",
"read, write, delete";
permission java.net.SocketPermission "127.0.0.1", "accept";
permission java.net.SocketPermission "localhost", "accept";
permission java.net.SocketPermission "${csinfo.serverhost}", "accept";
permission java.net.SocketPermission "${csinfo.trustedhost}", "accept";
// tracing files - BUG DERBY-613, DERBY-375 If ${derby.system.home} is set
// default location for trace files will be ${derby.system.home}. If
it is not set,
// default location will be ${user dir}.
// write permission for ${derby.system.home} is covered above by the line
// 'permission java.io.FilePermission "${derby.system.home}${/}-",
"read, write, delete";'
permission java.io.FilePermission "${user.dir}${/}*", "write";
// Import/export and other support files from these locations in tests
permission java.io.FilePermission "${user.dir}${/}extin${/}*", "read";
permission java.io.FilePermission "${user.dir}${/}extinout${/}*",
"read, write";
permission java.io.FilePermission "${user.dir}${/}extout${/}*", "write";
};
Deepa
Re: [Fwd: Re: derbynet/getCurrentProperties.java fails]
Posted by Daniel John Debrunner <dj...@debrunners.com>.
Deepa Remesh wrote:
>>Deepa Remesh wrote:
>>
>>
>>>Thanks Ole for posting the files.
>>>
>>>I did not catch this problem when I ran tests because I was using
>>>trunk/classes to run tests. When I tried with jars, the tests failed
>>>on my machine too. On looking at derby_tests.policy, the policy for
>>>running with classes covered writes to derby.system.home directory.
>>>But for derbynet.jar, permission to write to derby.system.home was not
>>>in the policy. I have added that and now the test
>>>derbynet/getCurrentProperties.java passes with jars. I am attaching
>>>the patch for policy file with this mail. If there are any comments,
>>>please let me know. I will upload it to JIRA once tests finish.
>>
>>Why does derbynet.jar need to write to ${derby.system.home}?
>
>
> With patch for DERBY-375, the default value for
> derby.drda.traceDirectory is "If the derby.system.home property has
> been set, it is the default. Otherwise, the default is the current
> directory." With this change network server may have to write to trace
> files to ${derby.system.home}.
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";
Dan.
Re: [Fwd: Re: derbynet/getCurrentProperties.java fails]
Posted by Deepa Remesh <dr...@gmail.com>.
> Deepa Remesh wrote:
>
> > Thanks Ole for posting the files.
> >
> > I did not catch this problem when I ran tests because I was using
> > trunk/classes to run tests. When I tried with jars, the tests failed
> > on my machine too. On looking at derby_tests.policy, the policy for
> > running with classes covered writes to derby.system.home directory.
> > But for derbynet.jar, permission to write to derby.system.home was not
> > in the policy. I have added that and now the test
> > derbynet/getCurrentProperties.java passes with jars. I am attaching
> > the patch for policy file with this mail. If there are any comments,
> > please let me know. I will upload it to JIRA once tests finish.
>
> Why does derbynet.jar need to write to ${derby.system.home}?
With patch for DERBY-375, the default value for
derby.drda.traceDirectory is "If the derby.system.home property has
been set, it is the default. Otherwise, the default is the current
directory." With this change network server may have to write to trace
files to ${derby.system.home}.
> I'll add comments to the file that added permissions need comments as to
> why they are added.
>
> The policies granted to the classes directory is a super-set of the
> permissions granted to the other jars, but that does not imply a
> permission granted to the classes is applicable for a specific jar.
>
Since the policies granted to classes directory is a superset, it
includes read,write, delete to derby.system.home (which is required by
derby.jar). With patch for DERBY-375, derbynet.jar requires write
permission to ${derby.system.home}. I have only added the following
line to derby_tests.policy:
"permission java.io.FilePermission "${derby.system.home}${/}*", "write"; "
I have modified the comments in derby_tests.policy to indicate why I
added it. If that is not clear, I can modify it.
Deepa