[
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
