It passed regressions on Windows and Solaris with classes, sane and insane jars. Manual inspection showed permissions to be restricted as expected on both platform types.
This patch builds on the previous proof-of-concept patches. It is not for commit yet, I still need to rewrite the Java 7 level code to use reflection, so as not to force use of Java 7. In order to compile the patch you need a Java 7 JDK as the patch stands.
I have called the patch "basic" since I need to make another patch to include:
- implement the property persistence needed for old databases to avoid suddenly starting to use the new feature when upgrading, cf discussion with Kathey. See also separate question thread below.
The patch now also restricts permission for created directories, albeit only for the lowests level if many levels are created with a a single mkdir. This can be improved if you think it is important/necessary, we just need to do more analysis of what parts of the path already exists during creation.
Tests. I'd like feed-back on this. It's a bit hard to really test this automatically since our tests run within one OS user only. Naturally, we can inspect the file masks (on Posix/Unix), but we'd have to use the same methods in JDK 6 that we presently use to set them, so I am not sure it adds value. Likewise for NTFS ACLs, we would rely on the very same privitimes I use in JDK 7 to manipulate the ACLs. Up to now, I have used manual inspection of the file system permission using tools provided (ls -l on Unix, and The Windows explorer on Windows).
Reviewers: Please help finding "holes", i.e. place where I have forgotten to limit permissions for for files and dirs created. I have gone through the code, but I can have missed some instances. Bwt, I did not do anything for the tools (ij, dblook).
The patch only ever restricts permissions of files that are created, never on existing files . This would preclude using the feature to "tighten up" and existing database. Is this the best approach? I think if one wants to secure an existing database, it's better to do it manually using OS level tools, and then start using the feature (lest it happens only gradually, piece-meal over time).
 In the code, in some places I check if there was a file/dir created, in other places where it is statically known to be a new file/dir, I do not check. Verifying the correctness of this could be useful
Detailed patch comments:
Enables using Java 7 for compilation. This will go away when I move to use reflection, but I'll make a new JIRA and attach this so we don't lose the code. I imagine at some point we will want to start using Java 7/8 going forward.
Implements the new static method limitAccessToOwner(File file). This will do the right thing for Unix and Windows if running on >= Java 6 and >= Java 7 respectively. Note: I have presumed that Windows use NTFS with ACLs enabled here. If the fs on Window were, say, an NFS share, it would not work since this would have POSIX permission. I guess we could improve this in a follow-up patch. If running on a Windows FAT system, which doesn't have permissions, the method would do nothing. a noop would also ensue if NTFS had the ACLs turned off.
The Java 7 source level delegate which implements the NTFS ACL part of the above logic. When I move to use reflection, this code will move to FileUtil.java.
Enables building of FileUtil7 with Java 7, will go away in next patch.
The Derby property "derby.storage.useDefaultFilePermissions".
limit access to files created during export.
Creates derby.system.home if missing with restricted permissions.
Creation of derby.system.home, db directory ("wombat"), system.properties file with restricted permissions.
Creation of derby.log with restricted permissions.
Creation of lck file with restricted permissions (NIO).
Added limitAccessToOwner to interface. In the code, StorageFile is often used interchangably with File; so StorageFile also implements exists() etc al.
Implements StorageFile. An empty implementation of limitAccessToOwner since this is the base class for read-only stream implementations of the StorageFile interface. I.e. not file creation happens here.
Implements StorageFile. The one implemenation of StorageFile that does create files in the "real" file system. Forwards to FileUtil.limitAccessToOwner.
Implements StorageFile. No disk file system access, so an empty implementation of limitAccessToOwner.
Creation of the tmp directory with restricted permissions.
Creation of the log directory and its files with restricted permissions.
Creation of the backup directories and contents with restricted permissions (but see FileUtils#copyDirectory, #copyFile also).
Creation of the db lock file with restricted permissions (but see also NIO getExclusiveFileLock in DirFile4).
Used for lobs? In any case, tighted up to use restricted permissions.
Jar file logic: restricted permissions.
container creation, regular and backup with restricted permissions
extra int'l for a "caused by string".
Dss trace (server): restricted permissions for trace directory and trace files.
Implements StorageFile. Test only.
The new code when running on Java 7 on Windows needs the extra RuntimePermission "accessUserInformation" (to determine the file's owner) when run with the Security Manager. I have added that to the default "server.policy" file, and the "template.policy", as well as were needed to run the tests. The tests also needed some more "read" file permissions.
Changes to be able to use Java 7. Will be rolled back when I move to use reflection.