Daniel John Debrunner wrote:
Rick Hillegas wrote:
Daniel John Debrunner wrote:
Rick Hillegas wrote:
I have taken a stab at describing various security expectations
which customers might have and also how we could balance these
expectations against the desire to run the network server "secure
by default". The following wiki page addresses these issues:
http://wiki.apache.org/db-derby/SecurityExpectations
With the Basic policy some thought needs to be put into other
resources/tasks:
backup of a database
restore of a database (?)
import/export of data
installing/replacing jar files
The described policy would mean all of those file resources need to
be placed in the system home.
Dan.
Thanks, Dan. I don't have any inspired ideas here. We could introduce
a new property, say, "derby.io.directories". This would resolve to a
classpath-like list of directories, that is, a list of directories
separated by the operating-system-specific separator (; or :). The
meaning of this property would be "Derby has read and write access to
all file-system trees rooted in these directories." At network
startup, the Basic policy file could grant read/write access to all
of these trees.
We could introduce extra granularity here. E.g., separate properties
for read access and write access; or separate properties for
backup/restore, import/export, and jar loading. However, I would err
on the side of keeping this simple. If a customer needs greater
granularity, then they can customize the Basic policy themselves.
Your question prompted me to consider the following other loose-end:
We probably want to minimize upgrade problems for customers who have
put their logs on separate devices. In constructing the Basic policy,
we could walk all of the immediate subdirectories under
derby.system.home, looking for the service.properties files there and
then grant read/write/delete access to all directories identified by
the logDevice property stored in those service.properties files. I
don't think this would catch all of the cases but it might be
helpful. Alternatively, it might be overkill. What do you think?
A really simple solution to these would be to grant permission in the
Basic policy to derby.jar to read/write/delete to '<<ALL FILES>>'. On
windows/unix/linux systems the os file permissions will be in play and
the accessibility to files by derby would match other client/server
database systems.
Then as you say, anyone wanting finer granularity can write their own
policy file.
Dan.
I like simple solutions and am happy with this approach.
Regards,
-Rick
