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: Proposal for change in test harness & security manager
Date Mon, 10 Oct 2005 18:25:17 GMT
Kathey Marsden wrote:

> Daniel John Debrunner wrote:
> 
> 
>>Currently any test that runs the network server as a separate java
>>executable uses the security manager and a policy file (nwsvr.policy)
>>for the network server's JVM. This is a good step but I've been looking
>>to improve the situation to run most tests under the security manager
>>(by default).
>>
>>Current Behaviour
>>-----------------
>>
>>The harness determins a code base from the class path and sets this as
>>the property csinfo.codebase for the policy file. This code base will
>>correspond to either the classes directory or the directory containing
>>derby jar files. The policy file (nwsvr.policy) then has a set of
>>permissions that are granted to the code base, which is the entire derby
>>code.
>>
>>Issue with the current behaviour
>>--------------------------------
>>
>>Granting permissions to a single code base that includes all the derby
>>code can lead to hidden bugs, especially due to the fact the test
>>harness does not need to be secure and is not designed that way, whereas
>>the other derby components need to be secure. For example, the test
>>harness needs to read and modify system properties so that permission is
>>granted, now the engine should not be needing that permission but due to
>>the single code base in the policy file, it has that permission and now
>>silently could start to depend on it.
>>
>> 
>>
> 
> 
> I can see that this is an issue for the embedded policy file.   Since
> network server only had  to deal with the  server side access, we  did
> not have to grant the permissions needed by the harness to the codebase
> in the nwsvr.policy file.    I do  have some other concerns about the
> permissions in the nwsvr.policy file and  I am wondering if they will be
> addressed by your changed.
> 
> 1) There are a bunch of permissions that hare needed only by specific
> tests, for instance quite a few for sysinfo.
>  permission java.io.FilePermission "${csinfo.codebase}/derby.jar",
> "read";  etc.  Will these be in the derby_tests.policy?

I would only check in a policy file (first step) that ensured the tests
running today under the security manager continued to run. Thus if a
permission is required it will be in the policy file. Now that specific
one you mention is actually a bug (I believe). Thus it will be in the
policy file but I would enter a Jira entry indicating that the code
needs to be modified not to require that permission. The permission in
the policy file would have a comment indicating the bug number.

> 2) For a sane  build we seemed to need,  permission
> java.lang.RuntimePermission "accessDeclaredMembers";  which would be
> good to not have available to an insane build. Will this still be required?

As above, if required it will have to be there, but it may be a bug that
that is required. At the moment I'm only testing insane but will move
onto sane once I have sane working (and before committing). I'd seen
this one as a potential issue thanks to your comments in nwsvr.policy. :-)

> 
> 3) Will both network server and embedded tests use the same
> derby_tests.policy file?  Are there any issues with the extra
> permissions needed by one or the other?

Yes single policy file, I don't see any case where extra permissions are
needed, remember permissions will be granted to the individual jars,
thus I don't think derby.jar needs any more permissions to run under the
network server. Can you think of any issues?

Thanks,
Dan.



Mime
View raw message