[
https://issues.apache.org/jira/browse/DERBY-5363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dag H. Wanvik updated DERBY-5363:
---------------------------------
Attachment: derby-5363-basic-1.stat
derby-5363-basic-1.diff
Uploading derby-5363-basic-1.
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 [1]. 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).
[1] 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:
M java/build/org/apache/derbyPreBuild/PropertySetter.java
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.
M java/engine/org/apache/derby/iapi/services/io/FileUtil.java
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.
A java/engine/org/apache/derby/iapi/services/io/FileUtil7.java
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.
M java/engine/org/apache/derby/iapi/services/io/build.xml
Enables building of FileUtil7 with Java 7, will go away in next patch.
M java/engine/org/apache/derby/iapi/reference/Property.java
The Derby property "derby.storage.useDefaultFilePermissions".
M java/engine/org/apache/derby/impl/load/ExportWriteData.java
limit access to files created during export.
M java/engine/org/apache/derby/impl/services/monitor/FileMonitor.java
Creates derby.system.home if missing with restricted permissions.
M
java/engine/org/apache/derby/impl/services/monitor/StorageFactoryService.java
Creation of derby.system.home, db directory ("wombat"), system.properties file
with restricted permissions.
M java/engine/org/apache/derby/impl/services/stream/SingleStream.java
Creation of derby.log with restricted permissions.
M java/engine/org/apache/derby/impl/io/DirFile4.java
Creation of lck file with restricted permissions (NIO).
M java/engine/org/apache/derby/io/StorageFile.java
Added limitAccessToOwner to interface. In the code, StorageFile is often used
interchangably with File; so StorageFile also implements exists() etc al.
M java/engine/org/apache/derby/impl/io/InputStreamFile.java
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.
M java/engine/org/apache/derby/impl/io/DirFile.java
Implements StorageFile. The one implemenation of StorageFile that does create
files in the "real" file system. Forwards to FileUtil.limitAccessToOwner.
M java/engine/org/apache/derby/impl/io/vfmem/VirtualFile.java
M java/engine/org/apache/derby/impl/io/VFMemoryStorageFactory.java
Implements StorageFile. No disk file system access, so an empty implementation
of limitAccessToOwner.
M java/engine/org/apache/derby/impl/io/BaseStorageFactory.java
Creation of the tmp directory with restricted permissions.
M java/engine/org/apache/derby/impl/store/raw/log/LogToFile.java
Creation of the log directory and its files with restricted permissions.
M java/engine/org/apache/derby/impl/store/raw/RawStore.java
Creation of the backup directories and contents with restricted permissions
(but see FileUtils#copyDirectory, #copyFile also).
M
java/engine/org/apache/derby/impl/store/raw/data/BaseDataFileFactory.java
Creation of the db lock file with restricted permissions (but see also NIO
getExclusiveFileLock in DirFile4).
M
java/engine/org/apache/derby/impl/store/raw/data/StreamFileContainer.java
Used for lobs? In any case, tighted up to use restricted permissions.
M java/engine/org/apache/derby/impl/store/raw/data/RFResource.java
Jar file logic: restricted permissions.
M java/engine/org/apache/derby/impl/store/raw/data/RAFContainer.java
container creation, regular and backup with restricted permissions
M java/shared/org/apache/derby/shared/common/reference/MessageId.java
M java/engine/org/apache/derby/loc/messages.xml
extra int'l for a "caused by string".
M java/drda/org/apache/derby/impl/drda/DssTrace.java
Dss trace (server): restricted permissions for trace directory and trace files.
M
java/testing/org/apache/derbyTesting/functionTests/util/corruptio/CorruptFile.java
Implements StorageFile. Test only.
M java/drda/org/apache/derby/drda/server.policy
M java/drda/org/apache/derby/drda/template.policy
M
java/testing/org/apache/derbyTesting/functionTests/tests/lang/SecurityPolicyReloadingTest.modified.policy
M
java/testing/org/apache/derbyTesting/functionTests/tests/lang/SecurityPolicyReloadingTest.initial.policy
M
java/testing/org/apache/derbyTesting/functionTests/tests/jdbc4/noAbortPermission.policy
M
java/testing/org/apache/derbyTesting/functionTests/tests/derbynet/RuntimeInfoTest.policy
M
java/testing/org/apache/derbyTesting/functionTests/tests/derbynet/GetCurrentPropertiesTest.policy
M
java/testing/org/apache/derbyTesting/functionTests/tests/derbynet/NetworkServerControlApiTest.policy
M
java/testing/org/apache/derbyTesting/functionTests/tests/derbynet/ServerPropertiesTest.policy
M
java/testing/org/apache/derbyTesting/functionTests/util/derby_tests.policy
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.
M build.xml
M tools/jar/extraDBMSclasses.properties
Changes to be able to use Java 7. Will be rolled back when I move to use
reflection.
> Tighten default permissions of DB files with >= JDK6
> ----------------------------------------------------
>
> Key: DERBY-5363
> URL: https://issues.apache.org/jira/browse/DERBY-5363
> Project: Derby
> Issue Type: Improvement
> Reporter: Dag H. Wanvik
> Attachments: derby-5363-basic-1.diff, derby-5363-basic-1.stat,
> permission-5.diff, permission-5.stat, permission-6.diff, permission-6.stat,
> z.sql
>
>
> 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.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
