Unless it is completely unavoidable, it should be possible to install a later version AND NOT BREAK AN EXISTING APPLICATION. To do so is rude and can be very disruptive.
From: "Dag H. Wanvik" <email@example.com>
To: "Derby Discussion" <firstname.lastname@example.org>
Sent: Friday, September 2, 2011 1:31:46 PM
Subject: Opinions on new security feature requested
we are always working to make Derby more secure; in this day and age,
security is ever more on people's minds for obvious reasons;
IT systems are everywhere and the bad guys never tire of finding new
holes to break them. Up till now, Derby creates database files and logs
using the default operating system permission in effect. On Unix/linux
this is controlled by the umask of the process starting the Derby
engine, be in embedded or a standalone Derby network server. Similarly
on Windows, NTFS has a security model can be configured to give various
Now, often the defaults will allow other (than the one starting the VM)
OS users the permissions to read and possibly write to the database
files. This can be intention to allow several users to boot the same
(shared) database), or it can be accidental. In DERBY-5363 we have been
discussion use cases and scenarios for when it would be desirable to let
Derby be more secure than the default permissions. Other database also
do this, e.g. PostGreSQL, MS SQL server.
Typically, only the OS user creating the database would have access
(default behavior) unless one told the database to be lax and not worry
about tightening up the default OS permissions.
Obviously, one can achieve the same restrictive permissions, by setting
the umask to 0077 on Unix, or tweak the NTFS settings similarly
(Windows), but this requires some care and presumes that the users
remembers to do so (many people don't grok the NTFS security model..)
To be clear, one would be able to enable/disable this extra security by
providing Derby with a property setting, so the question is really what
is the msot appropriate default: use lax permissions (rely on the user
having tightened up be fore starting the VM), or use the new proactive
secure settings proposed in DERBY-5363.
Secure default pros:
- users will get better security by default. If one needs to share the
database files, one can use a property to get old, lax behavior.
- no need to change startup scripts to get better security
Secure default cons:
- upwards compatibility: if an installation relies on sharing database
files, on would have to start using a property after upgrading.
- requires at least Java 6 (on Unix), Java 7 on Windows/NTFS to work (an
incentive to upgrade, though :-)
In the discussion it as been suggested that many deployments, especially
of embedded Derby, rely on several OS users having permissions, so
changing the default Derby behavior would cause upgrade issues. Probably
for most client/server deployments, where the server is started from the
command line, it would be the same OS user starting the Derby server
every time. In mixed deployments (embedded, but the server is sometimes
started via the API), the latter may not hold true.
A possible trade-off between the concerns would thus be to start
embedded with the exisiting, lax permissions by default, but start the
server from the command line with a secure (restrictive) default. In
both cases, one would get the opposite behavior by providing a system
property on VM startup.
Before we settle the discussion on this, it would be good to hear what
you think! Thanks!