[
https://issues.apache.org/jira/browse/DERBY-5363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13093716#comment-13093716
]
Rick Hillegas commented on DERBY-5363:
--------------------------------------
Thanks for continuing to puzzle through these issues, Dag and Kathey. I am
afraid that I don't understand the tables posted yesterday.
I have a couple questions:
1) Besides derby.log and the network trace files, does Derby write any other
system level files?
2) Is this the problem with these files: append mode won't work if different
users boot the server/engine?
3) Or is there another problem: the files can't even be re-initialized
(overwritten) if different users boot the server/engine?
Thanks,
-Rick
> 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,
> 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
