db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5363) Tighten default permissions of DB files with >= JDK6
Date Wed, 14 Sep 2011 22:50:09 GMT

    [ https://issues.apache.org/jira/browse/DERBY-5363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13104965#comment-13104965
] 

Dag H. Wanvik commented on DERBY-5363:
--------------------------------------

The latest patch (derby-5363-full-1), broke some tests in the harness. It turns out the mechanism
I use for conveying to the engine it was booted from a CLI server is broken: I set a system
property in NetworkServerControl which is later consulted by the engine when creating new
files. The tests that broke installed their own security policies which did not include the
permission to set a system property. There is already a precedent for using internal system
properties, cf e.g. NetworkServerControl#installSecurityManager, but in that case, there is
no user specified security manager already installed, so setting the properties cannot fail.
In my case, we would have to impose a burden on the user to provide the needed permission
in the provided policy file, which is awkward, since we are talking about an internal system
property here. However, I didn't find any other way to provide the engine with this information
since the server uses the generic Class.forName method to boot the engine:
NetworkServerControlImpl.startNetworkServer, ca line 1009:

       cloudscapeDriver = (Driver) Class.forName(CLOUDSCAPE_DRIVER).newInstance();

and after that has been done it is too late (derby.log has already been created..) Any clever
ideas on how to let the engine know its been booted from the network server? I guess I could
try to load the class NetworkServerControlImpl and if available (which it would be in a server
context), read a public static member, but so far we have managed to avoid such "backward"
coupling from the embedded driver to the server code, so it doesn't sees a good solution either..


> 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-full-1.diff,
derby-5363-full-1.stat, derby-5363-server-1.diff, permission-5.diff, permission-5.stat, permission-6.diff,
permission-6.stat, property-table.png, 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

       

Mime
View raw message