Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Fri, 30 Sep 2011 16:14:45 +0000 (UTC)
From: "Dag H. Wanvik (Issue Comment Edited) (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: 
 <1913656166.11811.1317399285477.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=13118157#comment-13118157 ] 

Dag H. Wanvik edited comment on DERBY-5363 at 9/30/11 4:13 PM:
---------------------------------------------------------------

Uploading a follow-up patch: "derby-5363-followup", which adds a missing accessController block around setting the system property SERVER_STARTED_FROM_CMD_LINE. If missing, this would fail if running with a security manager specified on the command line. Regressions passed.
If the property permission is missing, the error is printed unconditionally and exit from main taken. Cf. DERBY-5413 which tried another (aborted) approach to make sure it got printed.
                
      was (Author: dagw):
    Uploading a follow-up patch: "derby-5363-followup", which adds a missing accessController block around setting the system property SERVER_STARTED_FROM_CMD_LINE. If missing, this would fail if running with a security manager specified on the command line. Regressions passed.
If the property permission is missing, the error is printed unconditionally and exit from main taken. Cf. DERBY-5413 which tried another (aborted) approach to make it got printed.
                  
> 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, derby-5363-basic-3.diff, derby-5363-basic-3.stat, derby-5363-followup.diff, 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-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, 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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira