db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Ondruška <peter.ondruska+de...@kaibo.eu>
Subject Re: Opinions on new security feature requested
Date Fri, 02 Sep 2011 20:55:25 GMT
+1 for more restrictive permissions. Actually when I run Derby on Unix
it runs under own user+group and database files are not accessible by

On Fri, Sep 2, 2011 at 7:31 PM, Dag H. Wanvik <dag.wanvik@oracle.com> wrote:
> Hi folks,
> 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 default permissions.
> 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!
> Dag

View raw message