db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (Updated) (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-5363) Tighten permissions of DB files to owner with >= JDK7
Date Thu, 06 Oct 2011 21:53:31 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-followup-unix.diff
                derby-5363-followup-unix.stat
                derby-5363-followup-unix.diff

Uploading a patch derby-5363-followup-unix to fix the problem seen on Solaris *not* running
under ZFS, but it should apply in general.

It turns out there is no guarantee the the underlying file system supports ACLs even though
Files#getFileAttributeView called with aclFileAttributeViewClz.class as an argument returns
an object. We also need to call the method:

     FileStore#supportsFileAttributeView(AclFileAttributeView.class)

to ascertain whether we have support for ACLs. To get at the current FileStore, we need to
inquire about that given a path:

     Files.getFileStore(<path>)

which requires the RuntimePermission "getFileStoreAttributes", hence the current patch's changes
to the policy files.

With the patch, RestrictiveFilePermissionsTest run OK on Solaris/UFS.  Rerunning regressions
on all platforms.



                
> Tighten permissions of DB files to owner with >= JDK7
> -----------------------------------------------------
>
>                 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-followup-linux.diff,
derby-5363-followup-linux.diff, derby-5363-followup-unix.diff, derby-5363-followup-unix.diff,
derby-5363-followup-unix.stat, derby-5363-followup.diff, 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-full-5.diff, derby-5363-full-5.stat,
derby-5363-limit-to-java7.diff, derby-5363-limit-to-java7.stat, derby-5363-limit-to-java7b.diff,
derby-5363-limit-to-java7b.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, 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.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message