You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Daniel John Debrunner (JIRA)" <ji...@apache.org> on 2007/05/18 22:01:16 UTC
[jira] Created: (DERBY-2673) If derby.system.home does not exist
Derby should only attempt to create that specific folder, not any missing
parents (ie. use File.mkdir(), not File.mkdirs())
If derby.system.home does not exist Derby should only attempt to create that specific folder, not any missing parents (ie. use File.mkdir(), not File.mkdirs())
---------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: DERBY-2673
URL: https://issues.apache.org/jira/browse/DERBY-2673
Project: Derby
Issue Type: Bug
Components: Security, Services
Affects Versions: 10.3.0.0
Reporter: Daniel John Debrunner
Assigned To: Daniel John Debrunner
Fix For: 10.3.0.0
Currently if the system property derby.system.home is set and the folder does not exist then derby will attempt to create the folder using File.mkdirs() on the value of derby.system.home.
This operation actually requires *read* permission on the parent directory (at least, maybe all folders in the path). E.g. when running the junit tests using ant:
derby.system.home=/home/djd/derby/trunk/junit_20070518_1216/system
and thus read permission is required on the parent
/home/djd/derby/trunk/junit_20070518_1216
The requirement to have this permission was added (I think) in JDK 1.5 and is intentional, see Sun bug 4932924
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4932924
The testing policy file does not include this permission thus some of the tests fail when running using ant. [I think most tests pass because the driver gets loaded outside of the security manager, thus allowing the mkdirs() to succeed.]
I'm not sure that this permission should simply be added to the test policy file. This would mean that users would also have to add such an entry in their policy file. Of course the entry would need to be the explicit parent path, I don't think ${derby.system.home}${/}.. would be portable.
[actually
The reason for not adding it is that from a security point of view it expands the range of files Derby can read to be outside of the ${derby.system.home}. I think being able to encapsulate Derby's permissions to files under ${derby.system.home} is a better security model.
The simple change in Derby behaviour that seems to fix this is to change the mkdirs() to a mkdir(). The visible change to users would be that parent folder of derby.system.home must exist, previously Derby would have created all non-existent parent directories.
I think this is an acceptable change in behaviour for a security issue and unlikely to cause many issues for users.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-2673) If derby.system.home does not exist
Derby should only attempt to create that specific folder, not any missing
parents (ie. use File.mkdir(), not File.mkdirs())
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Daniel John Debrunner updated DERBY-2673:
-----------------------------------------
Derby Info: (was: [Release Note Needed, Existing Application Impact])
Knut Anders' cool trick will mean no change in behaviour. Thanks!
> If derby.system.home does not exist Derby should only attempt to create that specific folder, not any missing parents (ie. use File.mkdir(), not File.mkdirs())
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2673
> URL: https://issues.apache.org/jira/browse/DERBY-2673
> Project: Derby
> Issue Type: Bug
> Components: Security, Services
> Affects Versions: 10.3.0.0
> Reporter: Daniel John Debrunner
> Assigned To: Daniel John Debrunner
> Fix For: 10.3.0.0
>
>
> Currently if the system property derby.system.home is set and the folder does not exist then derby will attempt to create the folder using File.mkdirs() on the value of derby.system.home.
> This operation actually requires *read* permission on the parent directory (at least, maybe all folders in the path). E.g. when running the junit tests using ant:
> derby.system.home=/home/djd/derby/trunk/junit_20070518_1216/system
> and thus read permission is required on the parent
> /home/djd/derby/trunk/junit_20070518_1216
> The requirement to have this permission was added (I think) in JDK 1.5 and is intentional, see Sun bug 4932924
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4932924
> The testing policy file does not include this permission thus some of the tests fail when running using ant. [I think most tests pass because the driver gets loaded outside of the security manager, thus allowing the mkdirs() to succeed.]
> I'm not sure that this permission should simply be added to the test policy file. This would mean that users would also have to add such an entry in their policy file. Of course the entry would need to be the explicit parent path, I don't think ${derby.system.home}${/}.. would be portable.
> [actually
> The reason for not adding it is that from a security point of view it expands the range of files Derby can read to be outside of the ${derby.system.home}. I think being able to encapsulate Derby's permissions to files under ${derby.system.home} is a better security model.
> The simple change in Derby behaviour that seems to fix this is to change the mkdirs() to a mkdir(). The visible change to users would be that parent folder of derby.system.home must exist, previously Derby would have created all non-existent parent directories.
> I think this is an acceptable change in behaviour for a security issue and unlikely to cause many issues for users.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2673) If derby.system.home does not exist
Derby should only attempt to create that specific folder, not any missing
parents (ie. use File.mkdir(), not File.mkdirs())
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497034 ]
Daniel John Debrunner commented on DERBY-2673:
----------------------------------------------
I would have thought that for databases under derby.system.home (which is the case in DERBY-2644) then intermediate folders should be created.
Especially since the permission failing is stack traces is granted to derby.jar by the testing policy file, thus something else is going on.
> If derby.system.home does not exist Derby should only attempt to create that specific folder, not any missing parents (ie. use File.mkdir(), not File.mkdirs())
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2673
> URL: https://issues.apache.org/jira/browse/DERBY-2673
> Project: Derby
> Issue Type: Bug
> Components: Security, Services
> Affects Versions: 10.3.0.0
> Reporter: Daniel John Debrunner
> Assigned To: Daniel John Debrunner
> Fix For: 10.3.0.0
>
>
> Currently if the system property derby.system.home is set and the folder does not exist then derby will attempt to create the folder using File.mkdirs() on the value of derby.system.home.
> This operation actually requires *read* permission on the parent directory (at least, maybe all folders in the path). E.g. when running the junit tests using ant:
> derby.system.home=/home/djd/derby/trunk/junit_20070518_1216/system
> and thus read permission is required on the parent
> /home/djd/derby/trunk/junit_20070518_1216
> The requirement to have this permission was added (I think) in JDK 1.5 and is intentional, see Sun bug 4932924
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4932924
> The testing policy file does not include this permission thus some of the tests fail when running using ant. [I think most tests pass because the driver gets loaded outside of the security manager, thus allowing the mkdirs() to succeed.]
> I'm not sure that this permission should simply be added to the test policy file. This would mean that users would also have to add such an entry in their policy file. Of course the entry would need to be the explicit parent path, I don't think ${derby.system.home}${/}.. would be portable.
> [actually
> The reason for not adding it is that from a security point of view it expands the range of files Derby can read to be outside of the ${derby.system.home}. I think being able to encapsulate Derby's permissions to files under ${derby.system.home} is a better security model.
> The simple change in Derby behaviour that seems to fix this is to change the mkdirs() to a mkdir(). The visible change to users would be that parent folder of derby.system.home must exist, previously Derby would have created all non-existent parent directories.
> I think this is an acceptable change in behaviour for a security issue and unlikely to cause many issues for users.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2673) If derby.system.home does not exist
Derby should only attempt to create that specific folder, not any missing
parents (ie. use File.mkdir(), not File.mkdirs())
Posted by "Knut Anders Hatlen (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497042 ]
Knut Anders Hatlen commented on DERBY-2673:
-------------------------------------------
What about replacing file.mkdirs() with (file.mkdir() || file.mkdirs())? Wouldn't that preserve the old behaviour for those applications which need the parents to be created, and also remove the need for read permission if the parent directory exists?
> If derby.system.home does not exist Derby should only attempt to create that specific folder, not any missing parents (ie. use File.mkdir(), not File.mkdirs())
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2673
> URL: https://issues.apache.org/jira/browse/DERBY-2673
> Project: Derby
> Issue Type: Bug
> Components: Security, Services
> Affects Versions: 10.3.0.0
> Reporter: Daniel John Debrunner
> Assigned To: Daniel John Debrunner
> Fix For: 10.3.0.0
>
>
> Currently if the system property derby.system.home is set and the folder does not exist then derby will attempt to create the folder using File.mkdirs() on the value of derby.system.home.
> This operation actually requires *read* permission on the parent directory (at least, maybe all folders in the path). E.g. when running the junit tests using ant:
> derby.system.home=/home/djd/derby/trunk/junit_20070518_1216/system
> and thus read permission is required on the parent
> /home/djd/derby/trunk/junit_20070518_1216
> The requirement to have this permission was added (I think) in JDK 1.5 and is intentional, see Sun bug 4932924
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4932924
> The testing policy file does not include this permission thus some of the tests fail when running using ant. [I think most tests pass because the driver gets loaded outside of the security manager, thus allowing the mkdirs() to succeed.]
> I'm not sure that this permission should simply be added to the test policy file. This would mean that users would also have to add such an entry in their policy file. Of course the entry would need to be the explicit parent path, I don't think ${derby.system.home}${/}.. would be portable.
> [actually
> The reason for not adding it is that from a security point of view it expands the range of files Derby can read to be outside of the ${derby.system.home}. I think being able to encapsulate Derby's permissions to files under ${derby.system.home} is a better security model.
> The simple change in Derby behaviour that seems to fix this is to change the mkdirs() to a mkdir(). The visible change to users would be that parent folder of derby.system.home must exist, previously Derby would have created all non-existent parent directories.
> I think this is an acceptable change in behaviour for a security issue and unlikely to cause many issues for users.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2673) If derby.system.home does not exist
Derby should only attempt to create that specific folder, not any missing
parents (ie. use File.mkdir(), not File.mkdirs())
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497048 ]
Daniel John Debrunner commented on DERBY-2673:
----------------------------------------------
Interesting idea Knut Anders, I'll try it out.
> If derby.system.home does not exist Derby should only attempt to create that specific folder, not any missing parents (ie. use File.mkdir(), not File.mkdirs())
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2673
> URL: https://issues.apache.org/jira/browse/DERBY-2673
> Project: Derby
> Issue Type: Bug
> Components: Security, Services
> Affects Versions: 10.3.0.0
> Reporter: Daniel John Debrunner
> Assigned To: Daniel John Debrunner
> Fix For: 10.3.0.0
>
>
> Currently if the system property derby.system.home is set and the folder does not exist then derby will attempt to create the folder using File.mkdirs() on the value of derby.system.home.
> This operation actually requires *read* permission on the parent directory (at least, maybe all folders in the path). E.g. when running the junit tests using ant:
> derby.system.home=/home/djd/derby/trunk/junit_20070518_1216/system
> and thus read permission is required on the parent
> /home/djd/derby/trunk/junit_20070518_1216
> The requirement to have this permission was added (I think) in JDK 1.5 and is intentional, see Sun bug 4932924
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4932924
> The testing policy file does not include this permission thus some of the tests fail when running using ant. [I think most tests pass because the driver gets loaded outside of the security manager, thus allowing the mkdirs() to succeed.]
> I'm not sure that this permission should simply be added to the test policy file. This would mean that users would also have to add such an entry in their policy file. Of course the entry would need to be the explicit parent path, I don't think ${derby.system.home}${/}.. would be portable.
> [actually
> The reason for not adding it is that from a security point of view it expands the range of files Derby can read to be outside of the ${derby.system.home}. I think being able to encapsulate Derby's permissions to files under ${derby.system.home} is a better security model.
> The simple change in Derby behaviour that seems to fix this is to change the mkdirs() to a mkdir(). The visible change to users would be that parent folder of derby.system.home must exist, previously Derby would have created all non-existent parent directories.
> I think this is an acceptable change in behaviour for a security issue and unlikely to cause many issues for users.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (DERBY-2673) If derby.system.home does not exist
Derby should only attempt to create that specific folder, not any missing
parents (ie. use File.mkdir(), not File.mkdirs())
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Daniel John Debrunner closed DERBY-2673.
----------------------------------------
Resolution: Fixed
Committed revision 539614 - patch with code as described by Knu Anders (plus comments).
> If derby.system.home does not exist Derby should only attempt to create that specific folder, not any missing parents (ie. use File.mkdir(), not File.mkdirs())
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2673
> URL: https://issues.apache.org/jira/browse/DERBY-2673
> Project: Derby
> Issue Type: Bug
> Components: Security, Services
> Affects Versions: 10.3.0.0
> Reporter: Daniel John Debrunner
> Assigned To: Daniel John Debrunner
> Fix For: 10.3.0.0
>
>
> Currently if the system property derby.system.home is set and the folder does not exist then derby will attempt to create the folder using File.mkdirs() on the value of derby.system.home.
> This operation actually requires *read* permission on the parent directory (at least, maybe all folders in the path). E.g. when running the junit tests using ant:
> derby.system.home=/home/djd/derby/trunk/junit_20070518_1216/system
> and thus read permission is required on the parent
> /home/djd/derby/trunk/junit_20070518_1216
> The requirement to have this permission was added (I think) in JDK 1.5 and is intentional, see Sun bug 4932924
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4932924
> The testing policy file does not include this permission thus some of the tests fail when running using ant. [I think most tests pass because the driver gets loaded outside of the security manager, thus allowing the mkdirs() to succeed.]
> I'm not sure that this permission should simply be added to the test policy file. This would mean that users would also have to add such an entry in their policy file. Of course the entry would need to be the explicit parent path, I don't think ${derby.system.home}${/}.. would be portable.
> [actually
> The reason for not adding it is that from a security point of view it expands the range of files Derby can read to be outside of the ${derby.system.home}. I think being able to encapsulate Derby's permissions to files under ${derby.system.home} is a better security model.
> The simple change in Derby behaviour that seems to fix this is to change the mkdirs() to a mkdir(). The visible change to users would be that parent folder of derby.system.home must exist, previously Derby would have created all non-existent parent directories.
> I think this is an acceptable change in behaviour for a security issue and unlikely to cause many issues for users.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2673) If derby.system.home does not exist
Derby should only attempt to create that specific folder, not any missing
parents (ie. use File.mkdir(), not File.mkdirs())
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-2673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497023 ]
Kathey Marsden commented on DERBY-2673:
---------------------------------------
The mkdirs() call in rg.apache.derby.impl.store.raw.RawStore.backup seems to be causing some of the Encryption failures in DERBY-2644. Is it reasonable to change this to mkdir() as well or would we expect to be able to create the parent directories.
> If derby.system.home does not exist Derby should only attempt to create that specific folder, not any missing parents (ie. use File.mkdir(), not File.mkdirs())
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-2673
> URL: https://issues.apache.org/jira/browse/DERBY-2673
> Project: Derby
> Issue Type: Bug
> Components: Security, Services
> Affects Versions: 10.3.0.0
> Reporter: Daniel John Debrunner
> Assigned To: Daniel John Debrunner
> Fix For: 10.3.0.0
>
>
> Currently if the system property derby.system.home is set and the folder does not exist then derby will attempt to create the folder using File.mkdirs() on the value of derby.system.home.
> This operation actually requires *read* permission on the parent directory (at least, maybe all folders in the path). E.g. when running the junit tests using ant:
> derby.system.home=/home/djd/derby/trunk/junit_20070518_1216/system
> and thus read permission is required on the parent
> /home/djd/derby/trunk/junit_20070518_1216
> The requirement to have this permission was added (I think) in JDK 1.5 and is intentional, see Sun bug 4932924
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4932924
> The testing policy file does not include this permission thus some of the tests fail when running using ant. [I think most tests pass because the driver gets loaded outside of the security manager, thus allowing the mkdirs() to succeed.]
> I'm not sure that this permission should simply be added to the test policy file. This would mean that users would also have to add such an entry in their policy file. Of course the entry would need to be the explicit parent path, I don't think ${derby.system.home}${/}.. would be portable.
> [actually
> The reason for not adding it is that from a security point of view it expands the range of files Derby can read to be outside of the ${derby.system.home}. I think being able to encapsulate Derby's permissions to files under ${derby.system.home} is a better security model.
> The simple change in Derby behaviour that seems to fix this is to change the mkdirs() to a mkdir(). The visible change to users would be that parent folder of derby.system.home must exist, previously Derby would have created all non-existent parent directories.
> I think this is an acceptable change in behaviour for a security issue and unlikely to cause many issues for users.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.