db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "TomohitoNakayama" <tomon...@basil.ocn.ne.jp>
Subject Re: Proposal for change in test harness & security manager
Date Sun, 09 Oct 2005 17:13:32 GMT
Hello.

Just to confirm my understanding ....

I read your proposal as defining security policies for each jar files.
Does the proposal assume that the same jar file is always executed in same security environments
in the test ?

Best regards.

/*

         Tomohito Nakayama
         tomonaka@basil.ocn.ne.jp
         tomohito@rose.zero.ad.jp
         tmnk@apache.org

         Naka
         http://www5.ocn.ne.jp/~tomohito/TopPage.html

*/
----- Original Message ----- 
From: "Daniel John Debrunner" <djd@debrunners.com>
To: "derby-dev" <derby-dev@db.apache.org>
Sent: Monday, October 10, 2005 1:35 AM
Subject: Proposal for change in test harness & security manager


> 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.
> 
> Proposed change
> ---------------
> 
> I have a more specific properties file (derby_tests.policy) that has a
> section for each derby jar file with code, and grants only the required
> (and reasonable) permissions for each jar. E.g. derby.jar is not granted
> any socket related permissions and derbynet.jar is not granted any
> access to the database files. With this file incorrect permissions that
> need to be granted are obvious and bugs can be entered against them.
> 
> In addition a section in the policy file will exist for the classes
> directory with a superset of the permissions. This is for when the tests
> are run directly out of the classes directory.
> 
> There is a chance that the tests will pass under the classes and fail
> with the jars with a contribution or change. The risk is small (and most
> likely would point to a bug). Comments can be added in the policy file
> indicating if changes are made to the classes section that similar
> changes might be needed to the jar sections and tests should also be run
> using the jars.
> 
> 
> Justification
> -------------
> 
> I strongly believe that the single code base approach today is not
> sufficent for Derby's security testing, due to the potential for hidden
> bugs. In switching to this new style I think I've found three bugs so
> far against Derby related to permissions, including one potentially
> serious one where a create index fails due to no access to a temp file.
> I need to look at that one more. I think the number of bugs (so far)
> shows the change is a good one.
> 
> 
> Status
> ------
> 
> [I'll add this to the wiki in a while]
> 
> The first checkin would switch to the new policy file and hence just
> continue to run the network server under the security manager.
> Subsequent checkins would enable running tests under the security
> manager including embedded tests and the client side tests. There will
> be more e-mail on that before it occurs.
> 
> I'm also modifying an old Cloudscape internal document that discussed
> and listed the permissions to bring it up to date and add it to the
> Derby site.
> 
> I think I'll be ready for the first checkin in a few days.
> 
> BTW - the code that currently does handle the security manager and
> policy file in the harness is well written, it expanded to the standard
> tests very easily.
> 
> Comments etc?
> Dan.



-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.11.13/124 - Release Date: 2005/10/07


Mime
View raw message