[DERBY-5363] Tighten permissions of DB files to owner with >= JDK7

• Type: Improvement
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Fix Version/s: 10.9.1.0
• Component/s: Miscellaneous, Services, Store
• Issue & fix info: Release Note Needed
• Bug behavior facts: Security
• Assignee: Dag H. Wanvik
• Reporter: Dag H. Wanvik
• Created: 29/Jul/11 23:00
• Updated: 21/Jan/15 00:23
• Resolved: 09/Oct/11 20:48

Description

Before Java 6, files created by Derby would have the default
permissions of the operating system context. Under Unix, this would
depend on the effective umask of the process that started the Java VM.

In Java 6 and 7, there are methods available that allows tightening up this
(File.setReadable, setWritable), making it less likely that somebody
would accidentally run Derby with a too lenient default.

I suggest we take advantage of this, and let Derby by default (in Java
6 and higher) limit the visibility to the OS user that starts the VM,
e.g. on Unix this would be equivalent to running with umask 0077. More
secure by default is good, I think.

We could have a flag, e.g. "derby.storage.useDefaultFilePermissions"
that when set to true, would give the old behavior.

Issue Links

• incorporates: DERBY-5492 Restrictive file permissions: permissions removed also for owner on NTFS if Acl does not contain explicit entry for owner
• is related to: DERBY-5442 Create documentation for restrictive file permissions feature
• is related to: DERBY-6521 Improve error handling when restricting file permissions
• relates to: DERBY-5434 On linux with IBM JDK 1.7 suites.All does not run at all failing with java.lang.reflect.InvocationTargetException
• relates to: DERBY-6160 Fixes needed to documentation topics on security policy permissions
• relates to: DERBY-6209 Add release note omitted with 10.9 for new required Security Manager permissions after DERBY-5363
• relates to: DERBY-6258 Restrict permissions on BACKUP.HISTORY

Sub-Tasks

• Create documentation for restrictive file permissions feature: Closed