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.
2) Is it possible to temporarily give up a set of granted security
privileges in a class and get them again on the way out? Basically
import only wants the write derby access privilege and export only
wants the read derby access privilege.
3) Could the routines be moved into a separate jar that would get a
different set of security manager privileges?
4) we could get rid of the current interfaces all together and change
to require streams rather than files for the user files. This may be
a lot slower and does raise backward compatibility issues. The point
of import/export is to allow easy/fast bulk load/unload, so doesn't
really solve the issue.
