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 15:56:27 +0000 (UTC)
From: "Kathey Marsden (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: 
 <559118405.45636.1313596587307.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <507378079.20088.1311980529620.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (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=13086413#comment-13086413 ] 

Kathey Marsden commented on DERBY-5363:
---------------------------------------

I think not with the API which is normally used for embedded server scenarios, but perhaps for the command line start up where we also start a security manager and try to be more secure by default.    I can think of at least  one product that requires multiple users to be able to start Network Server, but I am pretty sure they use the API. I will check.  It might be good to check with the user list too.

Would it be possible to make the enhanced restrictions only occur on new databases and ones that have been created with the restrictions? The thing that makes me most wary about messing with  permissions is that the errors that users get with mixed permissions are pretty ugly,  like container cannot be opened or can't read some specific transaction log file during recovery. We sometimes see these errors now with an existing database with liberal permission is accessed by a new user with more restrictive umask and then opened by another user who can't access the new files.  What needs to be done is some chmods and adjust the umask of the secondary user  to fix it up, but unfortunately often, by the time I see it, somebody has gotten interested in those log and seg0 directories and deleted something corrupting the database.    If the new default permissions were to take effect with preexisting databases, we might see this scenario more often.


> 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