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] [Issue Comment Edited] (DERBY-5363) Tighten default permissions of DB files with >= JDK6
Date Tue, 13 Sep 2011 21:29:08 GMT

    [ https://issues.apache.org/jira/browse/DERBY-5363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13104001#comment-13104001
] 

Dag H. Wanvik edited comment on DERBY-5363 at 9/13/11 9:27 PM:
---------------------------------------------------------------

Uploading a new version which is a sum of the basic patch + the server patch + a new test
(which is the main new contribution of this patch): RestrictiveFilePermissionsTest.

Some minor omissions were added to the basic patch's code (a couple of places where we had
forgotten some created files/dirs). 

Also a small fix for JUnit was necessary to make one constructor of NetworkServerTestSetup
used in the test, work.

The test will only do anything when run under Java 7. Also, if the default umask (or Windows
equivalent) is set such that only  the owner gets access, the test can't really work and skips
the test.

If you can imagine other userful test cases, that would be appreciated. I have tried to wade
through the code and docs to find places where directories and files are created, but it's
easy to miss some.

Running regressions.

Footnote: the reason why we can *restrict* but not test permission with Java 6 is that this
would require running a test with another OS user; there is not way to inspect the permissions,
only to restrict them, essentially. Cf File.setWriteable & friends.

      was (Author: dagw):
    Uploading a new version which is a sum of the basic patch + the server patch + a new test
(which is the main new contribution of this patch): RestrictiveFilePermissionsTest.

Some minor omissions were added to the basic patch's code (a couple of places where we had
forgotten some created files/dirs). 

Also a small fix for JUnit was necessary to make one constructor of NetworkServerTestSetup
used in the test, work.

The test will only do anything when run under Java 7. Also, if the default umask (or Windows
equivalent) is set such that only  the owner gets access, the test can't really work and skips
the test.

If you can imagine other userful test cases, that would be appreciated. I have tried to wade
through the code and docs to find places where directories and files are created, but it's
easy to miss some.

Running regressions.
  
> 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
>          Components: Miscellaneous, Services, Store
>            Reporter: Dag H. Wanvik
>            Assignee: Dag H. Wanvik
>         Attachments: derby-5363-basic-1.diff, derby-5363-basic-1.stat, derby-5363-basic-2.diff,
derby-5363-basic-2.stat, derby-5363-basic-3.diff, derby-5363-basic-3.stat, derby-5363-full-1.diff,
derby-5363-full-1.stat, derby-5363-server-1.diff, permission-5.diff, permission-5.stat, permission-6.diff,
permission-6.stat, property-table.png, 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

        

Mime
View raw message