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] [Issue Comment Edited] (DERBY-5363) Tighten default permissions of DB files with >= JDK6
Date Wed, 10 Aug 2011 18:26:27 GMT

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

Dag H. Wanvik edited comment on DERBY-5363 at 8/10/11 6:25 PM:
---------------------------------------------------------------

Uploading the patch "permissions-6" which fixes the booleans mentioned by Rick, and added
logic for Windows w/ACLs as well. For that platform, I remove all ACL entries that do not
belong to the file owner. If understand this correctly, this will effectively limit access
to other principals (users and groups). The patch currently requires a Java 7 compiler, but
once the code is finalized, we should probably rewrite this to use reflection, so we won't
impose another burden on Derby developers, e.g. Java 7 is not available for the Mac yet. I
still need to add logic for the directories.

As for the class factoring, I am open to suggestions, I found this placement the most logical.
The code in some places used java.io.File directly, in othe rplaces it uses the abstraction
StoragetFile. There is a precedence for vacuous implementations here, see releaseExclusiveFileLock
for example. I added a forwarding in CorruptFile for the new method similar to the pattern
for the other methods in StorageFle interface.

As for the boolean result checked in FileUtil.checkResult, the Javadoc says "true if and only
if the operation succeeded. The operation will fail if the user does not have permission to
change the access permissions of this abstract pathname. If readable is false and the underlying
file system does not implement a read permission, then the operation will fail."  Presumably,
since we created the file, we have permissions to change permissions on it. We skip "setReadable"
for Windows, so we should not see that either. I chose to use FileNotFoundException to avoid
polluting the Derby io code with more checked exceptions since this should not happen for
ordinary user operation. Sightly more sneaky is the fact I use FileNotFoundException to wrap
Java security access violation: for NTFS/Java 7 the method Files#getOwner needs the RuntimePermission
"accessUserInformation", and if the application is running with a security manager that permission
needs to be added to the code base. Ill see if I can make this error stand out better. I added
this permission to the defautl policy and sample, cf. the patch "permission-6".

The patch is not ready for commit yet, but feel free to review it. Running regressions now.



      was (Author: dagw):
    Uploading the patch "permissions-6" which fixes the booleans mentioned by Rick, and added
logic for Windows w/ACLs as well. For that platform, I remove all ACL entries that do not
belong to the file owner. If understand this correctly, this will effectively limit access
to other principals (users and groups). The patch currently requires a Java 7 compiler, but
once the code is finalized, we should probably rewrite this to use reflection, so we won't
impose another burden on Derby developers, e.g. Java 7 is not availabel fro the Mac yet. I
still need to add logic for the directories.

As for the class factoring, I am open to suggestions, I found this placement the most logical.
The code in some places used java.io.File directly, in othe rplaces it uses the abstraction
StoragetFile. There is a precedence for vacuous implementations here, see releaseExclusiveFileLock
for example. I added a forwarding in CorruptFile for the new method similar to the pattern
for the other methods in StorageFle interface.

As for the boolean result checked in FileUtil.checkResult, the Javadoc says "true if and only
if the operation succeeded. The operation will fail if the user does not have permission to
change the access permissions of this abstract pathname. If readable is false and the underlying
file system does not implement a read permission, then the operation will fail."  Presumably,
since we created the file, we have permissions to change permissions on it. We skip "setReadable"
for Windows, so we should not see that either. I chose to use FileNotFoundException to avoid
polluting the Derby io code with more checked exceptions since this should not happen for
ordinary user operation. Sightly more sneaky is the fact I use FileNotFoundException to wrap
Java security access violation: for NTFS/Java 7 the method Files#getOwner needs the RuntimePermission
"accessUserInformation", and if the application is running with a security manager that permission
needs to be added to the code base. Ill see if I can make this error stand out better. I added
this permission to the defautl policy and sample, cf. the patch "permission-6".

The logic for directories is still missing. The patch is not ready for commit yet, but feel
free to review it. Running regressions now.


  
> 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

       

Mime
View raw message