Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Wed, 17 Aug 2011 23:14:27 +0000 (UTC)
From: "Dag H. Wanvik (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: 
 <736994004.47087.1313622867229.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=13086668#comment-13086668 ] 

Dag H. Wanvik edited comment on DERBY-5363 at 8/17/11 11:13 PM:
----------------------------------------------------------------

Unfortunately, we don't check whether a database exists (in StorageFactoryService#createServiceRoot before we have already created derby.log. So we would have to chose whether to use default restrictive access permission for derby.log. Then, when we have read system.properties we would know whether this database should use restrictive flags or not for the remainder of the booted time.

So let's see if this behavior would work: 

We have a property, derby.storage.useDefaultFilePermissions, which would only default to 'false' when we started a database server from the command line (along with Java security).

This means that in this case, derby.log would always get restrictive permission. (To avoid this one would henceforth need to specify the property to be 'true').

When connecting, if we have a *new* database, we would continue to use restrictive permissions for that database. We would store this fact in system.properties.

If we connect to an existing database, we would check system.properties for the presence of derby.storage.useDefaultFilePermissions. If it is not seen (soft or hard upgrade), we would assume the value to be true, and update system.properties with this fact if hard upgrade. If it is seen, we use that value for it.

So, as far as compatibility, if the property is *not* specified when starting a server (as would be the case for oblivious users upgrading), the only change seen would be that derby.log would (usually) have more restrictive permissions than earlier - other (new) db files would be created with the old laxer scheme as before.

Does this sound acceptable?


      was (Author: dagw):
    Unfortunately, we don't check whether a database exists (in StorageFactoryService#createServiceRoot before we have already created derby.log. So we would have to chose whether to use default restrictive access permission for derby.log. Then, when we have read system.properties we would know whether this database should use restrictive flags or not for the remainder of the booted time.

So let's see if this behavior would work: 

We have a property, derby.storage.useDefaultFilePermissions, which would only default to 'false' when we started a database server from the command line (along with Java security).

This means that in this case, derby.log would always get restrictive permission. (To avoid this one would henceforth need to specify the property to be 'true').

When connecting, if we have a *new* database, we would continue to use restrictive permissions for that database. We would store this fact in system.properties.

If we connect to an existing database, we would check system.properties for the presence of derby.storage.useDefaultFilePermissions. If it is not seen (soft or hard upgrade), we would assume the value to be true, and update system.properties with this fact. If it is seen, we use that value for it.

So, as far as compatibility, if the property is *not* specified when starting a server (as would be the case for oblivious users upgrading), the only change seen would be that derby.log would (usually) have more restrictive permissions than earlier - other (new) db files would be created with the old laxer scheme as before.

Does this sound acceptable?

  
> 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, permission-6.diff, permission-6.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