Mike Matrigali wrote:
I am hoping to get a discussion going on how the right way to fix these
issues. As I understand it the ability to read/write files is currently
inherited from derby.jar where the import/export system procedures
currently reside. The problem is that this means the they can be used
to bypass the normal database level read/write access to derby system
files: property files, database files, log files, temp files. As dan
has pointed out I believe the current policy files may allow in one
database but access files in a completely different database so the
scope of the files is larger than just the current database.
I don't know much about security manager possibilities so maybe someone
who knows can point the way.
Some approaches:
1) try to code access privileges in the routines themselves, that is
separate from java security manager. Basically
disallow access to derby files by adding code logic to determine if
the files being read/written are derby files. This is not too hard to
do if you
only want to disallow under the current database subtree, but gets
harder under any derby subtree.
So I think this approach would check for files named:
derby.properties
system.properties
log/log*.dat
log/log.ctrl
log/logmirror.ctrl
seg0/*.dat
I think temporary files also, and I think they can be anywhere.
I like the above approach, simple but likely covers most of situations.
The list would need to include jar/*.jar. I also think you mean
service.properties and not system.properties.
A "right" Java fix might be to introduce new Derby permissions for
import and export. Then derby.jar would need to be granted those
permissions in order to import/export. The permissions could use
java.io.FilePermission (write for Export, read for Import).
Dan.
