Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Tue, 9 Aug 2011 15:56:27 +0000 (UTC)
From: "Rick Hillegas (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: 
 <761277212.20502.1312905387196.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <507378079.20088.1311980529620.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Issue Comment Edited] (DERBY-5363) Tighten default
 permissions of DB files with >= JDK6
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ 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