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] [Updated] (DERBY-5363) Tighten default permissions of DB files with >= JDK6
Date Thu, 22 Sep 2011 03:29:26 GMT

     [ 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

        

Mime
View raw message