[
https://issues.apache.org/jira/browse/DERBY-5363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13081713#comment-13081713
]
Rick Hillegas edited comment on DERBY-5363 at 8/9/11 3:54 PM:
--------------------------------------------------------------
Thanks for the patch, Dag.
Attaching z.sql. This is a script which creates a database named db2, exports a
table, performs a sort, and exits prematurely, leaving a tmp directory and
database lock files hanging around. On my Mac OSC laptop, I have run this
script with the trunk (after applying the permission-5 patch) and with 10.8.1.2.
Here's what the permissions look like for the trunk with the patch applied:
drwxr-xr-x 8 rh161140 rh161140 272 Aug 9 08:44 db2
-rw------- 1 rh161140 rh161140 611 Aug 9 08:44 derby.log
total 24
-rw------- 1 rh161140 rh161140 38 Aug 9 08:44 db.lck
-rw------- 1 rh161140 rh161140 4 Aug 9 08:44 dbex.lck
drwxr-xr-x 14 rh161140 rh161140 476 Aug 9 08:45 log
drwxr-xr-x 73 rh161140 rh161140 2482 Aug 9 08:44 seg0
-rw------- 1 rh161140 rh161140 851 Aug 9 08:44 service.properties
drwxr-xr-x 2 rh161140 rh161140 68 Aug 9 08:45 tmp
-rw------- 1 rh161140 rh161140 8192 Aug 9 08:44 db2/seg0/cf0.dat
-rw------- 1 rh161140 rh161140 4 Aug 9 08:44 /Users/rh161140/junk/z.export
And here's what the permissions look like for 10.8.1.2:
drwxr-xr-x 8 rh161140 rh161140 272 Aug 9 08:43 db2
-rw-r--r-- 1 rh161140 rh161140 604 Aug 9 08:43 derby.log
total 24
-rw-r--r-- 1 rh161140 rh161140 38 Aug 9 08:43 db.lck
-rw-r--r-- 1 rh161140 rh161140 4 Aug 9 08:43 dbex.lck
drwxr-xr-x 14 rh161140 rh161140 476 Aug 9 08:43 log
drwxr-xr-x 73 rh161140 rh161140 2482 Aug 9 08:43 seg0
-rw-r--r-- 1 rh161140 rh161140 851 Aug 9 08:43 service.properties
drwxr-xr-x 2 rh161140 rh161140 68 Aug 9 08:43 tmp
-rw-r--r-- 1 rh161140 rh161140 8192 Aug 9 08:43 db2/seg0/cf0.dat
-rw-r--r-- 1 rh161140 rh161140 4 Aug 9 08:43 /Users/rh161140/junk/z.export
So it looks as though the permissions on the directories could be tightened up.
A couple comments on the patch:
o There are several vacuous implementations of limitAccessToOwner(). This may
indicate that the original class factoring is not aligned with what you are
trying to do. Probably not worth fixing right now, but might be worth filing a
JIRA to fix in the future.
o FileUtil.limitAccessToOwner() - There are several places where you create new
Booleans. To avoid the object creation, you could just use Boolean.TRUE and
Boolean.FALSE.
o FileUtil.checkResult() - Not sure that FileNotFoundException is the only
possible problem which could fail this method.
Thanks,
-Rick
was (Author: rhillegas):
Thanks for the patch, Dag.
Attaching z.sql. This is a script which creates a database named db2, exports a
table, performs a sort, and exits prematurely, leaving a tmp directory and
database lock files hanging around. On my Mac OSC laptop, I have run this
script with the trunk (after applying the permission-5 patch) and with 10.8.1.2.
Here's what the permissions look like for the trunk with the patch applied:
drwxr-xr-x 8 rh161140 rh161140 272 Aug 9 08:44 db2
-rw------- 1 rh161140 rh161140 611 Aug 9 08:44 derby.log
total 24
-rw------- 1 rh161140 rh161140 38 Aug 9 08:44 db.lck
-rw------- 1 rh161140 rh161140 4 Aug 9 08:44 dbex.lck
drwxr-xr-x 14 rh161140 rh161140 476 Aug 9 08:45 log
drwxr-xr-x 73 rh161140 rh161140 2482 Aug 9 08:44 seg0
-rw------- 1 rh161140 rh161140 851 Aug 9 08:44 service.properties
drwxr-xr-x 2 rh161140 rh161140 68 Aug 9 08:45 tmp
-rw------- 1 rh161140 rh161140 8192 Aug 9 08:44 db2/seg0/cf0.dat
-rw------- 1 rh161140 rh161140 4 Aug 9 08:44 /Users/rh161140/junk/z.export
And here's what the permissions look like for 10.8.1.2:
drwxr-xr-x 8 rh161140 rh161140 272 Aug 9 08:43 db2
-rw-r--r-- 1 rh161140 rh161140 604 Aug 9 08:43 derby.log
total 24
-rw-r--r-- 1 rh161140 rh161140 38 Aug 9 08:43 db.lck
-rw-r--r-- 1 rh161140 rh161140 4 Aug 9 08:43 dbex.lck
drwxr-xr-x 14 rh161140 rh161140 476 Aug 9 08:43 log
drwxr-xr-x 73 rh161140 rh161140 2482 Aug 9 08:43 seg0
-rw-r--r-- 1 rh161140 rh161140 851 Aug 9 08:43 service.properties
drwxr-xr-x 2 rh161140 rh161140 68 Aug 9 08:43 tmp
-rw-r--r-- 1 rh161140 rh161140 8192 Aug 9 08:43 db2/seg0/cf0.dat
-rw-r--r-- 1 rh161140 rh161140 4 Aug 9 08:43 /Users/rh161140/junk/z.export
So it looks as though the permissions on the log, seg0, and tmp directories
could be tightened up.
A couple comments on the patch:
o There are several vacuous implementations of limitAccessToOwner(). This may
indicate that the original class factoring is not aligned with what you are
trying to do. Probably not worth fixing right now, but might be worth filing a
JIRA to fix in the future.
o FileUtil.limitAccessToOwner() - There are several places where you create new
Booleans. To avoid the object creation, you could just use Boolean.TRUE and
Boolean.FALSE.
o FileUtil.checkResult() - Not sure that FileNotFoundException is the only
possible problem which could fail this method.
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: permission-5.diff, permission-5.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
