[
https://issues.apache.org/jira/browse/DERBY-5363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dag H. Wanvik updated DERBY-5363:
---------------------------------
Attachment: derby-5363-full-4.stat
derby-5363-full-4.diff
Thanks for your diligent review, Knut! Uploading patch *-full-4 in which we:
- fixed the misguided StreamFileContainer exception, early draft cruft
- updated the JVMInfo to default to 7 if >= 8
- added creating a temporary table to testTmpDirectory test case
- changed naming to avoid having to list all tests that are part of the
majority group as suggested
- excluded the two lax cases from running if lax testing isn't supported
- in suite(), declared it as throws Exception and avoid swallowing the stack
trace of the underlying exception when calling checkAccessToOwner, ditto in
checkAccessToOwner
- added missing blank in warning string
- converted missing use of helper methods from BaseJDBCTestCase
- switched to using PrivilegedFileOpsForTests#exists
- removed spurious white space diff in NetworkServerTestSetup
- changed to using "/" since it's a cheaper pattern than reading the property
and works fine on Windows, too.
- removed instances of now superfluous exception handling code similar to this:
ioe instanceof FileNotFoundException &&
((FileNotFoundException)ioe).getCause() instanceof
AccessControlException) {
since limitAccessToOwner no longer wraps AccessControlException in a
IOException
Answers to your questions:
> - I was a little surprised that no security manager magic was needed to read
> this system property, like we have to do other places in the tests:
>
> + final static String pathSep = System.getProperty("file.separator");
>
> Maybe it's because the class is loaded before the security manager is
> installed? The constants File.separator or File.separatorChar could also be
> used, without any security manager concerns.
Not sure what's going on here. I tried to move it inside a test, but I still
got no security exception. I thought I had seen somewhere that this property
was safe to read, but I can't say where. I found this, though:
Cf. http://www.iam.ubc.ca/guides/javatut99/applet/practical/properties.html
which lists this as a legal property for an applet to read. I guess if a
property is considered safe for an applet to read, it's safe for an app running
under Java security, too..
> - testCliServerIsRestrictive(): Just curious... I thought
> assertDirectoryDeleted() already handled the cases where the file handles
> weren't closed just yet, so that sleeping shouldn't be necessary?
>
> + Thread.sleep(2000);
> + // ..so hopefully server will have closed files handles before
> + // we try to delete files:
> + assertDirectoryDeleted(traceDirF);
That's true, but I didn't like seeing the warning in my log.. ;-) This way,
mostly the method doesn't have to retry..
Rerunning regressions.
> 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-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-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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
