db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-5363) Tighten default permissions of DB files with >= JDK6
Date Mon, 29 Aug 2011 20:01:37 GMT

     [ 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

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

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


View raw message