[jira] [Commented] (DERBY-2925) Prevent export from overwriting existing files
[ https://issues.apache.org/jira/browse/DERBY-2925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16239681#comment-16239681 ] Bryan Pendleton commented on DERBY-2925: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-2232 > Prevent export from overwriting existing files > -- > > Key: DERBY-2925 > URL: https://issues.apache.org/jira/browse/DERBY-2925 > Project: Derby > Issue Type: Sub-task > Components: Tools >Affects Versions: 10.1.2.1, 10.2.2.0, 10.3.1.4, 10.4.1.3 >Reporter: Kathey Marsden >Assignee: Ramin Moazeni > Fix For: 10.3.1.4, 10.4.1.3, 10.6.2.1, 10.7.1.1 > > Attachments: DERBY-2925v0.diff, DERBY-2925v0.stat, DERBY-2925v1.diff, > DERBY-2925v1.stat, DERBY-2925v2.diff, DERBY-2925v2.stat, DERBY-2925v3.diff, > DERBY-2925v3.stat, DERBY-2925v4.diff, DERBY-2925v4.stat, DERBY-2925v5.diff, > DERBY-2925v5.stat, DERBY-2925v6.diff, DERBY-2925v6.stat, > derby-2925-07-aa-fileUrl.diff, releaseNote.html, releaseNotev0.html > > > Export should not overwrite existing files, but rather insist that the user > remove them before writing to the file. This will help prevent accidental or > intentional corruption of the database with export. This may introduce a > compatibility issue with export but because export is usually an attended > utility and not typically invoked as part of an application, I think the risk > is worth the additional security this will provide. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (DERBY-2925) Prevent export from overwriting existing files
[ https://issues.apache.org/jira/browse/DERBY-2925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16049897#comment-16049897 ] Rick Hillegas commented on DERBY-2925: -- This issue was tracked by CVE-2010-2232 along with the documentation improvement at https://issues.apache.org/jira/browse/DERBY-4708. The fixes appeared in Derby version10.6.2.1 (see http://db.apache.org/derby/releases/release-10.6.2.1.html), which was released on 2010-10-05. > Prevent export from overwriting existing files > -- > > Key: DERBY-2925 > URL: https://issues.apache.org/jira/browse/DERBY-2925 > Project: Derby > Issue Type: Sub-task > Components: Tools >Affects Versions: 10.1.2.1, 10.2.2.0, 10.3.1.4, 10.4.1.3 >Reporter: Kathey Marsden >Assignee: Ramin Moazeni > Fix For: 10.3.1.4, 10.4.1.3, 10.6.2.1, 10.7.1.1 > > Attachments: derby-2925-07-aa-fileUrl.diff, DERBY-2925v0.diff, > DERBY-2925v0.stat, DERBY-2925v1.diff, DERBY-2925v1.stat, DERBY-2925v2.diff, > DERBY-2925v2.stat, DERBY-2925v3.diff, DERBY-2925v3.stat, DERBY-2925v4.diff, > DERBY-2925v4.stat, DERBY-2925v5.diff, DERBY-2925v5.stat, DERBY-2925v6.diff, > DERBY-2925v6.stat, releaseNote.html, releaseNotev0.html > > > Export should not overwrite existing files, but rather insist that the user > remove them before writing to the file. This will help prevent accidental or > intentional corruption of the database with export. This may introduce a > compatibility issue with export but because export is usually an attended > utility and not typically invoked as part of an application, I think the risk > is worth the additional security this will provide. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] Commented: (DERBY-2925) Prevent export from overwriting existing files
[ https://issues.apache.org/jira/browse/DERBY-2925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12881665#action_12881665 ] Rick Hillegas commented on DERBY-2925: -- Thanks for the quick review, Bryan. Committed patch at subversion revision 957171. Prevent export from overwriting existing files -- Key: DERBY-2925 URL: https://issues.apache.org/jira/browse/DERBY-2925 Project: Derby Issue Type: Sub-task Components: Tools Affects Versions: 10.1.2.1, 10.2.2.0, 10.3.1.4, 10.4.1.3 Reporter: Kathey Marsden Assignee: Ramin Moazeni Fix For: 10.3.1.4, 10.4.1.3 Attachments: derby-2925-07-aa-fileUrl.diff, DERBY-2925v0.diff, DERBY-2925v0.stat, DERBY-2925v1.diff, DERBY-2925v1.stat, DERBY-2925v2.diff, DERBY-2925v2.stat, DERBY-2925v3.diff, DERBY-2925v3.stat, DERBY-2925v4.diff, DERBY-2925v4.stat, DERBY-2925v5.diff, DERBY-2925v5.stat, DERBY-2925v6.diff, DERBY-2925v6.stat, releaseNote.html, releaseNotev0.html Export should not overwrite existing files, but rather insist that the user remove them before writing to the file. This will help prevent accidental or intentional corruption of the database with export. This may introduce a compatibility issue with export but because export is usually an attended utility and not typically invoked as part of an application, I think the risk is worth the additional security this will provide. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2925) Prevent export from overwriting existing files
[ https://issues.apache.org/jira/browse/DERBY-2925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12881777#action_12881777 ] Rick Hillegas commented on DERBY-2925: -- Ported 957171 from trunk to 10.6 branch at subversion revision 957278. Prevent export from overwriting existing files -- Key: DERBY-2925 URL: https://issues.apache.org/jira/browse/DERBY-2925 Project: Derby Issue Type: Sub-task Components: Tools Affects Versions: 10.1.2.1, 10.2.2.0, 10.3.1.4, 10.4.1.3 Reporter: Kathey Marsden Assignee: Ramin Moazeni Fix For: 10.3.1.4, 10.4.1.3 Attachments: derby-2925-07-aa-fileUrl.diff, DERBY-2925v0.diff, DERBY-2925v0.stat, DERBY-2925v1.diff, DERBY-2925v1.stat, DERBY-2925v2.diff, DERBY-2925v2.stat, DERBY-2925v3.diff, DERBY-2925v3.stat, DERBY-2925v4.diff, DERBY-2925v4.stat, DERBY-2925v5.diff, DERBY-2925v5.stat, DERBY-2925v6.diff, DERBY-2925v6.stat, releaseNote.html, releaseNotev0.html Export should not overwrite existing files, but rather insist that the user remove them before writing to the file. This will help prevent accidental or intentional corruption of the database with export. This may introduce a compatibility issue with export but because export is usually an attended utility and not typically invoked as part of an application, I think the risk is worth the additional security this will provide. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2925) Prevent export from overwriting existing files
[ https://issues.apache.org/jira/browse/DERBY-2925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12881493#action_12881493 ] Bryan Pendleton commented on DERBY-2925: Your patch looks good to me, thanks for tracking this down. I'm a little surprised that in your test, you were able to do file: + fileName rather than file:// + fileName No other comments. +1 to commit. Prevent export from overwriting existing files -- Key: DERBY-2925 URL: https://issues.apache.org/jira/browse/DERBY-2925 Project: Derby Issue Type: Sub-task Components: Tools Affects Versions: 10.1.2.1, 10.2.2.0, 10.3.1.4, 10.4.1.3 Reporter: Kathey Marsden Assignee: Ramin Moazeni Fix For: 10.3.1.4, 10.4.1.3 Attachments: derby-2925-07-aa-fileUrl.diff, DERBY-2925v0.diff, DERBY-2925v0.stat, DERBY-2925v1.diff, DERBY-2925v1.stat, DERBY-2925v2.diff, DERBY-2925v2.stat, DERBY-2925v3.diff, DERBY-2925v3.stat, DERBY-2925v4.diff, DERBY-2925v4.stat, DERBY-2925v5.diff, DERBY-2925v5.stat, DERBY-2925v6.diff, DERBY-2925v6.stat, releaseNote.html, releaseNotev0.html Export should not overwrite existing files, but rather insist that the user remove them before writing to the file. This will help prevent accidental or intentional corruption of the database with export. This may introduce a compatibility issue with export but because export is usually an attended utility and not typically invoked as part of an application, I think the risk is worth the additional security this will provide. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2925) Prevent export from overwriting existing files
[ https://issues.apache.org/jira/browse/DERBY-2925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12516610 ] Kathey Marsden commented on DERBY-2925: --- Running suites.All with the patch I see these failures: Almost as though the permissions problem has moved. 3) testIllegalOps(org.apache.derbyTesting.functionTests.tests.lang.XMLTypeAndOpsTest)junit.framework.ComparisonFailure: Unexpected SQL state. expected:42Z7... but was:XJ00... at org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDBCTestCase.java:624) at org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDBCTestCase.java:659) at org.apache.derbyTesting.junit.BaseJDBCTestCase.assertSQLState(BaseJDBCTestCase.java:673) at org.apache.derbyTesting.junit.BaseJDBCTestCase.assertStatementError(BaseJDBCTestCase.java:854) at org.apache.derbyTesting.functionTests.tests.lang.XMLTypeAndOpsTest.testIllegalOps(XMLTypeAndOpsTest.java:352) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at org.apache.derbyTesting.junit.BaseTestCase.runBare(BaseTestCase.java:95) at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22) at junit.extensions.TestSetup$1.protect(TestSetup.java:19) at junit.extensions.TestSetup.run(TestSetup.java:23) at org.apache.derbyTesting.junit.BaseTestSetup.run(BaseTestSetup.java:57) Caused by: java.sql.SQLException: Java exception: 'Access denied (java.io.FilePermission xmlexport.del read): java.secur ity.AccessControlException'. at org.apache.derby.impl.jdbc.SQLExceptionFactory.getSQLException(SQLExceptionFactory.java:45) at org.apache.derby.impl.jdbc.Util.newEmbedSQLException(Util.java:88) at org.apache.derby.impl.jdbc.Util.javaException(Util.java:245) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:403) at org.apache.derby.impl.jdbc.TransactionResourceImpl.wrapInSQLException(TransactionResourceImpl.java:398) at org.apache.derby.impl.jdbc.TransactionResourceImpl.handleException(TransactionResourceImpl.java:346) at org.apache.derby.impl.jdbc.EmbedConnection.handleException(EmbedConnection.java:1572) at org.apache.derby.impl.jdbc.ConnectionChild.handleException(ConnectionChild.java:81) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1293) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java:1652) at org.apache.derby.impl.jdbc.EmbedCallableStatement.executeStatement(EmbedCallableStatement.java:116) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(EmbedPreparedStatement.java:1304) at org.apache.derbyTesting.junit.BaseJDBCTestCase.assertStatementError(BaseJDBCTestCase.java:849) ... 34 more Caused by: java.security.AccessControlException: Access denied (java.io.FilePermission xmlexport.del read) at java.security.AccessController.checkPermission(AccessController.java:104) at java.lang.SecurityManager.checkPermission(SecurityManager.java:547) at java.lang.SecurityManager.checkRead(SecurityManager.java:886) at java.io.File.exists(File.java:726) at org.apache.derby.iapi.util.PrivilegedFileOps$1.run(PrivilegedFileOps.java:60) at java.security.AccessController.doPrivileged(AccessController.java:242) at org.apache.derby.iapi.util.PrivilegedFileOps.exists(PrivilegedFileOps.java:57) at org.apache.derby.impl.load.Export.dataFileExists(Export.java:146) at org.apache.derby.impl.load.Export.doExport(Export.java:57) at org.apache.derby.impl.load.Export.exportTable(Export.java:172) at org.apache.derby.catalog.SystemProcedures.SYSCS_EXPORT_TABLE(SystemProcedures.java:1128) at org.apache.derby.exe.ac592dcde3x0114x19dfx7bc8xa650e7100.g0(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:64) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at org.apache.derby.impl.services.reflect.ReflectMethod.invoke(ReflectMethod.java:46) at org.apache.derby.impl.sql.execute.CallStatementResultSet.open(CallStatementResultSet.java:57) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:370) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1203) ... 38 more 4)
Re: [jira] Commented: (DERBY-2925) Prevent export from overwriting existing files
Kathey Marsden (JIRA) [EMAIL PROTECTED] writes:
[
https://issues.apache.org/jira/browse/DERBY-2925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515826
]
Kathey Marsden commented on DERBY-2925:
---
Ramin, do you think the issue is that we now need read permission for the
extout directory in the policy file, so we can determine if the file exists?
e.g.
Index:
java/testing/org/apache/derbyTesting/functionTests/util/derby_tests.policy
===
---
java/testing/org/apache/derbyTesting/functionTests/util/derby_tests.policy
(revision 559646)
+++
java/testing/org/apache/derbyTesting/functionTests/util/derby_tests.policy
(working copy)
@@ -70,7 +70,7 @@
// Import/export and other support files from these locations in tests
permission java.io.FilePermission ${user.dir}${/}extin${/}-, read;
permission java.io.FilePermission ${user.dir}${/}extinout${/}-, read,
write, delete;
- permission java.io.FilePermission ${user.dir}${/}extout${/}-, write;
+ permission java.io.FilePermission ${user.dir}${/}extout${/}-,
read,write;
permission java.io.FilePermission ${user.dir}${/}extinout, read,write;
Btw, are the the following entires in derby_tests.policy correct?
* It seems to me the entires for ${derbyTesting.clienthost} and
derbyTesting.serverhost should be the other way around? (I.e. the
accept is needed by the server, not the client.)
* The resolves are redundant (implied by both accept and connect),
but given in three of the four cases, why?
// combination of client and server side.
permission java.net.SocketPermission 127.0.0.1, accept,connect,resolve;
permission java.net.SocketPermission localhost, accept,connect,resolve;
permission java.net.SocketPermission ${derbyTesting.clienthost},
accept,connect;
permission java.net.SocketPermission ${derbyTesting.serverhost},
connect,resolve;
[jira] Commented: (DERBY-2925) Prevent export from overwriting existing files
[
https://issues.apache.org/jira/browse/DERBY-2925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515826
]
Kathey Marsden commented on DERBY-2925:
---
Ramin, do you think the issue is that we now need read permission for the
extout directory in the policy file, so we can determine if the file exists?
e.g.
Index:
java/testing/org/apache/derbyTesting/functionTests/util/derby_tests.policy
===
--- java/testing/org/apache/derbyTesting/functionTests/util/derby_tests.policy
(revision 559646)
+++ java/testing/org/apache/derbyTesting/functionTests/util/derby_tests.policy
(working copy)
@@ -70,7 +70,7 @@
// Import/export and other support files from these locations in tests
permission java.io.FilePermission ${user.dir}${/}extin${/}-, read;
permission java.io.FilePermission ${user.dir}${/}extinout${/}-, read,
write, delete;
- permission java.io.FilePermission ${user.dir}${/}extout${/}-, write;
+ permission java.io.FilePermission ${user.dir}${/}extout${/}-, read,write;
permission java.io.FilePermission ${user.dir}${/}extinout, read,write;
// These permissions are needed to load the JCE for encryption with Sun and
IBM JDK131.
[C:/svn2/trunk]
Kathey
Prevent export from overwriting existing files
--
Key: DERBY-2925
URL: https://issues.apache.org/jira/browse/DERBY-2925
Project: Derby
Issue Type: Sub-task
Components: Security, Tools
Affects Versions: 10.1.2.1, 10.2.2.0, 10.3.1.3, 10.4.0.0
Reporter: Kathey Marsden
Assignee: Ramin Moazeni
Attachments: DERBY-2925v0.diff, DERBY-2925v0.stat, DERBY-2925v1.diff,
DERBY-2925v1.stat, DERBY-2925v2.diff, DERBY-2925v2.stat, DERBY-2925v3.diff,
DERBY-2925v3.stat, releaseNotev0.html
Export should not overwrite existing files, but rather insist that the user
remove them before writing to the file. This will help prevent accidental or
intentional corruption of the database with export. This may introduce a
compatibility issue with export but because export is usually an attended
utility and not typically invoked as part of an application, I think the risk
is worth the additional security this will provide.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2925) Prevent export from overwriting existing files
[ https://issues.apache.org/jira/browse/DERBY-2925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515793 ] Myrna van Lunteren commented on DERBY-2925: --- I think this change has caused some failures in the tinderbox, see: http://dbtg.thresher.com/derby/test/Daily/jvm1.6/testing/Limited/testSummary-559500.html I think those should get resolved before backporting to 10.3. Prevent export from overwriting existing files -- Key: DERBY-2925 URL: https://issues.apache.org/jira/browse/DERBY-2925 Project: Derby Issue Type: Sub-task Components: Security, Tools Affects Versions: 10.1.2.1, 10.2.2.0, 10.3.1.3, 10.4.0.0 Reporter: Kathey Marsden Assignee: Ramin Moazeni Attachments: DERBY-2925v0.diff, DERBY-2925v0.stat, DERBY-2925v1.diff, DERBY-2925v1.stat, DERBY-2925v2.diff, DERBY-2925v2.stat, DERBY-2925v3.diff, DERBY-2925v3.stat, releaseNotev0.html Export should not overwrite existing files, but rather insist that the user remove them before writing to the file. This will help prevent accidental or intentional corruption of the database with export. This may introduce a compatibility issue with export but because export is usually an attended utility and not typically invoked as part of an application, I think the risk is worth the additional security this will provide. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2925) Prevent export from overwriting existing files
[ https://issues.apache.org/jira/browse/DERBY-2925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515825 ] Myrna van Lunteren commented on DERBY-2925: --- Also, I think it would make sense to specify the need for removal of the files in the documentation. Prevent export from overwriting existing files -- Key: DERBY-2925 URL: https://issues.apache.org/jira/browse/DERBY-2925 Project: Derby Issue Type: Sub-task Components: Security, Tools Affects Versions: 10.1.2.1, 10.2.2.0, 10.3.1.3, 10.4.0.0 Reporter: Kathey Marsden Assignee: Ramin Moazeni Attachments: DERBY-2925v0.diff, DERBY-2925v0.stat, DERBY-2925v1.diff, DERBY-2925v1.stat, DERBY-2925v2.diff, DERBY-2925v2.stat, DERBY-2925v3.diff, DERBY-2925v3.stat, releaseNotev0.html Export should not overwrite existing files, but rather insist that the user remove them before writing to the file. This will help prevent accidental or intentional corruption of the database with export. This may introduce a compatibility issue with export but because export is usually an attended utility and not typically invoked as part of an application, I think the risk is worth the additional security this will provide. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2925) Prevent export from overwriting existing files
[ https://issues.apache.org/jira/browse/DERBY-2925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12515021 ] Bryan Pendleton commented on DERBY-2925: The v3 patch looks great, Ramin! I have no further comments. Prevent export from overwriting existing files -- Key: DERBY-2925 URL: https://issues.apache.org/jira/browse/DERBY-2925 Project: Derby Issue Type: Sub-task Components: Security, Tools Affects Versions: 10.1.2.1, 10.2.2.0, 10.3.1.3, 10.4.0.0 Reporter: Kathey Marsden Assignee: Ramin Moazeni Attachments: DERBY-2925v0.diff, DERBY-2925v0.stat, DERBY-2925v1.diff, DERBY-2925v1.stat, DERBY-2925v2.diff, DERBY-2925v2.stat, DERBY-2925v3.diff, DERBY-2925v3.stat Export should not overwrite existing files, but rather insist that the user remove them before writing to the file. This will help prevent accidental or intentional corruption of the database with export. This may introduce a compatibility issue with export but because export is usually an attended utility and not typically invoked as part of an application, I think the risk is worth the additional security this will provide. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2925) Prevent export from overwriting existing files
[ https://issues.apache.org/jira/browse/DERBY-2925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514667 ] Bryan Pendleton commented on DERBY-2925: Hi Ramin, thanks for the v2 patch, it looks very good. I noticed that part of the patch involves code that will delete the partially-written output file(s) if the EXPORT operation fails. Is that a new behavior of EXPORT? It doesn't seem exactly related to the main issue of DERBY-2925. Do you think that the patch would still be valid without the deleteFile portion? Or is that a necessary component of the patch? thanks, bryan Prevent export from overwriting existing files -- Key: DERBY-2925 URL: https://issues.apache.org/jira/browse/DERBY-2925 Project: Derby Issue Type: Sub-task Components: Security, Tools Affects Versions: 10.1.2.1, 10.2.2.0, 10.3.1.3, 10.4.0.0 Reporter: Kathey Marsden Assignee: Ramin Moazeni Attachments: DERBY-2925v0.diff, DERBY-2925v0.stat, DERBY-2925v1.diff, DERBY-2925v1.stat, DERBY-2925v2.diff, DERBY-2925v2.stat Export should not overwrite existing files, but rather insist that the user remove them before writing to the file. This will help prevent accidental or intentional corruption of the database with export. This may introduce a compatibility issue with export but because export is usually an attended utility and not typically invoked as part of an application, I think the risk is worth the additional security this will provide. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (DERBY-2925) Prevent export from overwriting existing files
Ramin Moazeni (JIRA) wrote: I can remove the deleteFile(...) from the patch but to resolve the test errors, I think another way is to have a java stored procedure in in the .sql test to delete the file or simply use different filenames in each call to SYSCS_UTIL.SYSCS_EXPORT_... when we know a partially-written file will get created. The deleteFile sounds dangerous to me. I'd rather see one of these alternate solutions.
[jira] Commented: (DERBY-2925) Prevent export from overwriting existing files
[
https://issues.apache.org/jira/browse/DERBY-2925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12514355
]
Bryan Pendleton commented on DERBY-2925:
I'm comfortable with the general technique; I think it is acceptable for the
*EXPORT* family of procedures to refuse to overwrite existing files.
A couple comments on the v1 diff:
1) The IJ tests don't seem quite right to me: the tests refer to table
DERBY_2925_BOOK but it looks like the actual test table is called
derby_2925_lob? Some of the tests seem to be getting table-not-found errors.
2) I think we should put some effort into making the two messages as clear as
possible, both to make it as clear as possible that this is intentional
behavior (and not a bug), and to help people understand what they should do
when this happens. For example, we don't want people to waste time thinking
that there is a file permissions problem here, and trying to re-run the export
after fiddling with file permissions.
Here is a proposed suggestion for the text for the two messages:
+ msg
+nameXIE0S.S/name
+ textThe export operation was not performed, because the
specified output file ({0}) already exists. Export processing will not
overwrite an existing file, even if the process has permissions to write to
that file, due to security concerns, and to avoid accidental file damage.
Please either change the output file name in the export procedure arguments to
specify a file which does not exist, or delete the existing file, then retry
the export operation./text
+argfileName/arg
+/msg
+ msg
+nameXIE0T.S/name
+ textThe export operation was not performed, because the
specified large object auxiliary file ({0}) already exists. Export processing
will not overwrite an existing file, even if the process has permissions to
write to that file, due to security concerns, and to avoid accidental file
damage. Please either change the large object auxiliary file name in the export
procedure arguments to specify a file which does not exist, or delete the
existing file, then retry the export operation./text
+argfileName/arg
+/msg
Prevent export from overwriting existing files
--
Key: DERBY-2925
URL: https://issues.apache.org/jira/browse/DERBY-2925
Project: Derby
Issue Type: Sub-task
Components: Security, Tools
Affects Versions: 10.1.2.1, 10.2.2.0, 10.3.1.3, 10.4.0.0
Reporter: Kathey Marsden
Assignee: Ramin Moazeni
Attachments: DERBY-2925v0.diff, DERBY-2925v0.stat, DERBY-2925v1.diff,
DERBY-2925v1.stat
Export should not overwrite existing files, but rather insist that the user
remove them before writing to the file. This will help prevent accidental or
intentional corruption of the database with export. This may introduce a
compatibility issue with export but because export is usually an attended
utility and not typically invoked as part of an application, I think the risk
is worth the additional security this will provide.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2925) Prevent export from overwriting existing files
[ https://issues.apache.org/jira/browse/DERBY-2925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512631 ] Kathey Marsden commented on DERBY-2925: --- Hi Ramin, The patch looks good except I think it would be good to give import/export its own SQLState starting with XIE instead of reusing the existing store FILE_EXISTS message. Also it would be good to have test cases for writing the lob files. Kathey Prevent export from overwriting existing files -- Key: DERBY-2925 URL: https://issues.apache.org/jira/browse/DERBY-2925 Project: Derby Issue Type: Sub-task Components: Security, Tools Affects Versions: 10.1.2.1, 10.2.2.0, 10.3.1.3, 10.4.0.0 Reporter: Kathey Marsden Assignee: Ramin Moazeni Attachments: DERBY-2925v0.diff, DERBY-2925v0.stat Export should not overwrite existing files, but rather insist that the user remove them before writing to the file. This will help prevent accidental or intentional corruption of the database with export. This may introduce a compatibility issue with export but because export is usually an attended utility and not typically invoked as part of an application, I think the risk is worth the additional security this will provide. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-2925) Prevent export from overwriting existing files
[ https://issues.apache.org/jira/browse/DERBY-2925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12512321 ] Kathey Marsden commented on DERBY-2925: --- I think it is fine to reproduce with IJ and update importExportThruIJ.sql to test your change. The tests e.g. ImportExportBaseTest actually do call the procedure from a java program. It would be good to add a test there too. Prevent export from overwriting existing files -- Key: DERBY-2925 URL: https://issues.apache.org/jira/browse/DERBY-2925 Project: Derby Issue Type: Sub-task Components: Security, Tools Affects Versions: 10.1.2.1, 10.2.2.0, 10.3.1.3, 10.4.0.0 Reporter: Kathey Marsden Assignee: Ramin Moazeni Export should not overwrite existing files, but rather insist that the user remove them before writing to the file. This will help prevent accidental or intentional corruption of the database with export. This may introduce a compatibility issue with export but because export is usually an attended utility and not typically invoked as part of an application, I think the risk is worth the additional security this will provide. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
