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

Knut Anders Hatlen commented on DERBY-5363:
-------------------------------------------

I took a brief look at the basic-2 patch. A couple of comments:

1) This code may not do the intended in all locales (example: Turkish, 
"I".toLowerCase() returns "ı"):

+            os = PropertyUtil.getSystemProperty("os.name").toLowerCase();
+            onWindows = os.indexOf("windows") >= 0;

2) Maybe we could avoid checking the os.name property altogether? The 
limitAccessToOwnerNTFS() method seems to be coded to work on all platforms. If 
the platform supports ACL, use that to set the permission; otherwise, do 
nothing. Could we call that method unconditionally and make it return a value 
indicating whether or not it was successful, and then only fall back to the 
Java 6-way of doing things if that failed? Using the return value from 
Files.getFileAttributeView() to decide whether or not ACLs are supported sounds 
more robust than checking os.name.

3) FileUtil.limitAccessToOwner() sets many static fields on the first 
invocation. Is the first invocation guaranteed to be single-threaded, or is 
some kind of synchronization needed?

> 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, 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


Reply via email to