+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 others.
On Fri, Sep 2, 2011 at 7:31 PM, Dag H. Wanvik <dag.wan...@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 > >
