db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Db-derby Wiki] Update of "JavaPackageConventions" by BryanPendleton
Date Tue, 31 Oct 2006 17:18:55 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Db-derby Wiki" for change notification.

The following page has been changed by BryanPendleton:
http://wiki.apache.org/db-derby/JavaPackageConventions

The comment on the change is:
Edited notes from an email from Dan

New page:
This page explains some of the reasoning behind the Java package conventions that Derby uses.

org.apache.derby.* is currently used for all classes that form the runtime part of Derby,
the engine, the network server and the tools.

Other classes that are part of Derby but not part of the runtime are:
|| org.apache.derbyBuild.*   || Classes related to building Derby ||
|| org.apache.derbyTesting.* || Classes related to testing Derby ||
|| org.apache.derbyDemo.*    || Classes related to Derby demos ||

Such a high level split makes it much easier keep the clean separation between runtime (or
"product") classes and others. Prior to being open sourced all of the java code was in one
single package hierarchy and one top-level folder. This lead to frequent bugs with extra classes
becoming part of the product jars and to test code including engine code.

With the high level split the simple rule is: all classes in the runtime jars must start with
'org.apache.derby.'. If one moves the split down then the test becomes more complicated and
thus subject to mistakes. E.g. not o.a.d.demo or o.a.d.testing or o.a.d.build etc.

Then there is the security aspect, currently a Java function or procedure can map to any Java
class including those in the runtime code. This is a security problem with Derby, e.g. one
can call directly into low level Derby code from SQL thus inheriting the permissions granted
to derby.jar, possibly allowing a function/procedure to by-pass grant revoke and have full
access to the database files. One way to stop this is to disallow any SQL routine to map to
a class that starts with 'org.apache.derby.' and disallow the user code in the routine to
resolve classes that start with 'org.apache.derby.'. If one moves non-runtime code into that
name space then again the check to ensure the class is allowed or not becomes more complex,
the runtime code for example would have to allow routines that map to o.a.d.demo or o.a.d.testing.
(Or disallow a specific list, but that runs the risk of the list becoming out of date).

The split also protects us against the small chance of a bug, if the class loading for routines
treated the 'org.apache.derby.*' name space specially and thus all the tests work because
they use routines in that space (o.a.d.testing for example), but any user routine fails because
it is in a separate name space.


Mime
View raw message