You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Kathey Marsden (JIRA)" <ji...@apache.org> on 2013/04/09 00:06:16 UTC

[jira] [Comment Edited] (DERBY-5363) Tighten permissions of DB files to owner with >= JDK7

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

Kathey Marsden edited comment on DERBY-5363 at 4/8/13 10:06 PM:
----------------------------------------------------------------

Are the security manager permissions added for this issue, required for all uses of Derby including embedded?

"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."

I also don't understand why the tests needed read permission for the server trace file. Shouldn't t that be derbynet.jar that would need that?

Sorry for the ancient history question.  

                
      was (Author: kmarsden):
    Are the security manager permissions added for this issue, required for all uses of Derby including embedded?

"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."


Sorry for the ancient history question.  

                  
> Tighten permissions of DB files to owner with >= JDK7
> -----------------------------------------------------
>
>                 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
>             Fix For: 10.9.1.0
>
>         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-followup.diff, derby-5363-followup-linux.diff, derby-5363-followup-linux.diff, derby-5363-followup-unix.diff, derby-5363-followup-unix.diff, derby-5363-followup-unix.stat, derby-5363-full-1.diff, derby-5363-full-1.stat, derby-5363-full-2.diff, derby-5363-full-2.stat, derby-5363-full-3.diff, derby-5363-full-3.stat, derby-5363-full-4.diff, derby-5363-full-4.stat, derby-5363-full-5.diff, derby-5363-full-5.stat, derby-5363-limit-to-java7b.diff, derby-5363-limit-to-java7b.stat, derby-5363-limit-to-java7.diff, derby-5363-limit-to-java7.stat, derby-5363-server-1.diff, permission-5.diff, permission-5.stat, permission-6.diff, permission-6.stat, property-table.png, releaseNote.html, releaseNote.html, releaseNote.html, releaseNote.html, releaseNote.html, releaseNote.html, releaseNote.html, 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.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira