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 "Manjula Kutty (JIRA)" <de...@db.apache.org> on 2005/05/20 20:14:53 UTC
[jira] Created: (DERBY-304) If by mistake you give he location for the db backup as the db itself , then windows created directories recursively until windows crashes!
If by mistake you give he location for the db backup as the db itself , then windows created directories recursively until windows crashes!
--------------------------------------------------------------------------------------------------------------------------------------------
Key: DERBY-304
URL: http://issues.apache.org/jira/browse/DERBY-304
Project: Derby
Type: Bug
Components: Store
Versions: 10.1.0.0
Environment: With JDK 142 on Windows XP
Reporter: Manjula Kutty
Priority: Minor
If by mistake you give he location for the db backup as the db itself , then windows created directories recursively until it crashes!
Repro:
CallableStatement cs = conn.prepareCall("CALL SYSCS_UTIL.SYSCS_BACKUP_DATABASE_AND_ENABLE_LOG_ARCHIVE_MODE(?, ?)");
cs.setString(1, "c:/maildb");
cs.setInt(2, 1);
cs.execute();
cs.close();
result:
C:\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\..................... Until windows can not show the path!!!
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Resolved: (DERBY-304) If by mistake you give he location for
the db backup as the db itself , then windows created directories
recursively until windows crashes!
Posted by "Mike Matrigali (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-304?page=all ]
Mike Matrigali resolved DERBY-304:
----------------------------------
Fix Version: 10.2.0.0
Resolution: Fixed
> If by mistake you give he location for the db backup as the db itself , then windows created directories recursively until windows crashes!
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-304
> URL: http://issues.apache.org/jira/browse/DERBY-304
> Project: Derby
> Type: Bug
> Components: Store
> Versions: 10.1.1.0
> Environment: With JDK 142 on Windows XP
> Reporter: Manjula Kutty
> Assignee: Suresh Thalamati
> Priority: Minor
> Fix For: 10.2.0.0
> Attachments: derby-304.diff
>
> If by mistake you give he location for the db backup as the db itself , then windows created directories recursively until it crashes!
> Repro:
> CallableStatement cs = conn.prepareCall("CALL SYSCS_UTIL.SYSCS_BACKUP_DATABASE_AND_ENABLE_LOG_ARCHIVE_MODE(?, ?)");
> cs.setString(1, "c:/maildb");
> cs.setInt(2, 1);
> cs.execute();
> cs.close();
> result:
> C:\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\..................... Until windows can not show the path!!!
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: [jira] Commented: (DERBY-304) If by mistake you give he location
for the db backup as the db itself , then windows created directories recursively
until windows crashes!
Posted by Rajesh Kartha <ka...@Source-Zone.Org>.
Suresh Thalamati wrote:
>
>
> I tried getCanonicalFile() on Windows xp , it does not resolve
> symbolic/hard links.
>
I feared that must be the case for Windows
> Does the comparision u mentioned works on Linux if there are hard links ?
>
>
>
The comparision does not work on hard links but sure works for soft
links. Eitherway hard links are not for directories.
[
$ ln adir temp
ln: `adir': hard link not allowed for directory
]
Regards
-Rajesh
Re: [jira] Commented: (DERBY-304) If by mistake you give he location
for the db backup as the db itself , then windows created directories recursively
until windows crashes!
Posted by Daniel John Debrunner <dj...@apache.org>.
This is also a generic problem, not just a backup problem.
It would be good to disable reading/writing any file inside a database
directory structure, e.g. for backup, import/export etc.
Any requirement to use getAbsolutePath or getCanonical path will require
read permission on user.dir (I think Bryan said this), which is undesirable.
Dan.
Re: [jira] Commented: (DERBY-304) If by mistake you give he location
for the db backup as the db itself , then windows created directories recursively
until windows crashes!
Posted by Suresh Thalamati <su...@gmail.com>.
Hi Rajesh,
I tried getCanonicalFile() on Windows xp , it does not resolve
symbolic/hard links.
Does the comparision u mentioned works on Linux if there are hard links ?
Quick scan at the java doc for getCanonicalFile()/getCanonicalPath():
"This typically involves removing redundant names such as "." and ".."
from the pathname, resolving symbolic links (on UNIX platforms), and
converting drive letters to a standard case (on Microsoft Windows
platforms)."
Thanks
-suresht.
Rajesh Kartha (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/DERBY-304?page=comments#action_12364919 ]
>
> Rajesh Kartha commented on DERBY-304:
> -------------------------------------
>
> The (file.getCanonicalFile()) gives you the actual path for symbolic links. I am wondering if that could be used to compare the
> backup location and the actual database to be the same.
>
> Something like:
>
> f.getCanonicalFile().equals(f1.getCanonicalFile())
>
> This will return true is'f1' is a symbolic link to 'f'. I know for sure this works on Linux.
>
>
> -Rajesh
>
>
>
>
>>If by mistake you give he location for the db backup as the db itself , then windows created directories recursively until windows crashes!
>>-------------------------------------------------------------------------------------------------------------------------------------------
>>
>> Key: DERBY-304
>> URL: http://issues.apache.org/jira/browse/DERBY-304
>> Project: Derby
>> Type: Bug
>> Components: Store
>> Versions: 10.1.1.0
>> Environment: With JDK 142 on Windows XP
>> Reporter: Manjula Kutty
>> Priority: Minor
>
>
>>If by mistake you give he location for the db backup as the db itself , then windows created directories recursively until it crashes!
>>Repro:
>> CallableStatement cs = conn.prepareCall("CALL SYSCS_UTIL.SYSCS_BACKUP_DATABASE_AND_ENABLE_LOG_ARCHIVE_MODE(?, ?)");
>> cs.setString(1, "c:/maildb");
>> cs.setInt(2, 1);
>> cs.execute();
>> cs.close();
>>result:
>>C:\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\..................... Until windows can not show the path!!!
>
>
[jira] Commented: (DERBY-304) If by mistake you give he location
for the db backup as the db itself , then windows created directories
recursively until windows crashes!
Posted by "Rajesh Kartha (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-304?page=comments#action_12364919 ]
Rajesh Kartha commented on DERBY-304:
-------------------------------------
The (file.getCanonicalFile()) gives you the actual path for symbolic links. I am wondering if that could be used to compare the
backup location and the actual database to be the same.
Something like:
f.getCanonicalFile().equals(f1.getCanonicalFile())
This will return true is'f1' is a symbolic link to 'f'. I know for sure this works on Linux.
-Rajesh
> If by mistake you give he location for the db backup as the db itself , then windows created directories recursively until windows crashes!
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-304
> URL: http://issues.apache.org/jira/browse/DERBY-304
> Project: Derby
> Type: Bug
> Components: Store
> Versions: 10.1.1.0
> Environment: With JDK 142 on Windows XP
> Reporter: Manjula Kutty
> Priority: Minor
>
> If by mistake you give he location for the db backup as the db itself , then windows created directories recursively until it crashes!
> Repro:
> CallableStatement cs = conn.prepareCall("CALL SYSCS_UTIL.SYSCS_BACKUP_DATABASE_AND_ENABLE_LOG_ARCHIVE_MODE(?, ?)");
> cs.setString(1, "c:/maildb");
> cs.setInt(2, 1);
> cs.execute();
> cs.close();
> result:
> C:\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\..................... Until windows can not show the path!!!
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Assigned: (DERBY-304) If by mistake you give he location for
the db backup as the db itself , then windows created directories
recursively until windows crashes!
Posted by "Suresh Thalamati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-304?page=all ]
Suresh Thalamati reassigned DERBY-304:
--------------------------------------
Assign To: Suresh Thalamati
> If by mistake you give he location for the db backup as the db itself , then windows created directories recursively until windows crashes!
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-304
> URL: http://issues.apache.org/jira/browse/DERBY-304
> Project: Derby
> Type: Bug
> Components: Store
> Versions: 10.1.1.0
> Environment: With JDK 142 on Windows XP
> Reporter: Manjula Kutty
> Assignee: Suresh Thalamati
> Priority: Minor
>
> If by mistake you give he location for the db backup as the db itself , then windows created directories recursively until it crashes!
> Repro:
> CallableStatement cs = conn.prepareCall("CALL SYSCS_UTIL.SYSCS_BACKUP_DATABASE_AND_ENABLE_LOG_ARCHIVE_MODE(?, ?)");
> cs.setString(1, "c:/maildb");
> cs.setInt(2, 1);
> cs.execute();
> cs.close();
> result:
> C:\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\..................... Until windows can not show the path!!!
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-304) If by mistake you give he location for
the db backup as the db itself , then windows created directories
recursively until windows crashes!
Posted by "Mike Matrigali (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-304?page=all ]
Mike Matrigali updated DERBY-304:
---------------------------------
Description:
If by mistake you give he location for the db backup as the db itself , then windows created directories recursively until it crashes!
Repro:
CallableStatement cs = conn.prepareCall("CALL SYSCS_UTIL.SYSCS_BACKUP_DATABASE_AND_ENABLE_LOG_ARCHIVE_MODE(?, ?)");
cs.setString(1, "c:/maildb");
cs.setInt(2, 1);
cs.execute();
cs.close();
result:
C:\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\..................... Until windows can not show the path!!!
was:
If by mistake you give he location for the db backup as the db itself , then windows created directories recursively until it crashes!
Repro:
CallableStatement cs = conn.prepareCall("CALL SYSCS_UTIL.SYSCS_BACKUP_DATABASE_AND_ENABLE_LOG_ARCHIVE_MODE(?, ?)");
cs.setString(1, "c:/maildb");
cs.setInt(2, 1);
cs.execute();
cs.close();
result:
C:\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\..................... Until windows can not show the path!!!
I reviewed, ran tests and committed this patch:
m1_142:204>svn commit
Sending java\engine\org\apache\derby\iapi\services\io\FileUtil.java
Sending java\engine\org\apache\derby\iapi\store\access\FileResource.java
Sending java\engine\org\apache\derby\impl\sql\execute\JarDDL.java
Sending java\engine\org\apache\derby\impl\store\raw\RawStore.java
Sending java\engine\org\apache\derby\loc\messages_en.properties
Sending java\shared\org\apache\derby\shared\common\reference\SQLState.jav
a
Adding java\testing\org\apache\derbyTesting\functionTests\master\BackupP
athTests.out
Sending java\testing\org\apache\derbyTesting\functionTests\suites\storemo
re.runall
Adding java\testing\org\apache\derbyTesting\functionTests\tests\store\Ba
ckupPathTests.java
Adding java\testing\org\apache\derbyTesting\functionTests\tests\store\Ba
ckupPathTests_app.properties
Sending java\testing\org\apache\derbyTesting\functionTests\tests\store\co
pyfiles.ant
Transmitting file data ...........
Committed revision 379620.
> If by mistake you give he location for the db backup as the db itself , then windows created directories recursively until windows crashes!
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-304
> URL: http://issues.apache.org/jira/browse/DERBY-304
> Project: Derby
> Type: Bug
> Components: Store
> Versions: 10.1.1.0
> Environment: With JDK 142 on Windows XP
> Reporter: Manjula Kutty
> Assignee: Suresh Thalamati
> Priority: Minor
> Attachments: derby-304.diff
>
> If by mistake you give he location for the db backup as the db itself , then windows created directories recursively until it crashes!
> Repro:
> CallableStatement cs = conn.prepareCall("CALL SYSCS_UTIL.SYSCS_BACKUP_DATABASE_AND_ENABLE_LOG_ARCHIVE_MODE(?, ?)");
> cs.setString(1, "c:/maildb");
> cs.setInt(2, 1);
> cs.execute();
> cs.close();
> result:
> C:\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\..................... Until windows can not show the path!!!
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (DERBY-304) If by mistake you give he location for
the db backup as the db itself , then windows created directories
recursively until windows crashes!
Posted by "Suresh Thalamati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-304?page=all ]
Suresh Thalamati updated DERBY-304:
-----------------------------------
Attachment: derby-304.diff
DERBY-304: If the given backup path is same as the database home, backup
was failing in trying to copy the backup onto itself, while copying the
directories in the database home recursively into the backup.
Fix :
1) Do not allow backup path to be any derby database directory. A directory is
assumed to be a derby database directory if it has service.properties file in it.
2) copy files needed from the database home into the backup one by one
instead of recursive copy from the top directory.
3) while copying the directories under jar directory, copy each sub directory
separately without copying any subdirectories under them (There should not
be any unless if user has created explicitly or created backup at that location).
4) Log and Seg0 directory are NOT already copied recursively, this was changed as part of
online backup work (DERBY-239).
TESTS : derbyall test suite passed on Windows XP/JDK142, except for known failures.
It would be great if some can review and commit this patch.
svn stat:
M java\engine\org\apache\derby\impl\sql\execute\JarDDL.java
M java\engine\org\apache\derby\impl\store\raw\RawStore.java
M java\engine\org\apache\derby\iapi\services\io\FileUtil.java
M java\engine\org\apache\derby\iapi\store\access\FileResource.java
M java\engine\org\apache\derby\loc\messages_en.properties
M java\shared\org\apache\derby\shared\common\reference\SQLState.java
M java\testing\org\apache\derbyTesting\functionTests\tests\store\copyfiles.ant
A java\testing\org\apache\derbyTesting\functionTests\tests\store\BackupPathTests.java
A java\testing\org\apache\derbyTesting\functionTests\tests\store\BackupPathTests_app.properties
A java\testing\org\apache\derbyTesting\functionTests\master\BackupPathTests.out
M java\testing\org\apache\derbyTesting\functionTests\suites\storemore.runall
> If by mistake you give he location for the db backup as the db itself , then windows created directories recursively until windows crashes!
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-304
> URL: http://issues.apache.org/jira/browse/DERBY-304
> Project: Derby
> Type: Bug
> Components: Store
> Versions: 10.1.1.0
> Environment: With JDK 142 on Windows XP
> Reporter: Manjula Kutty
> Assignee: Suresh Thalamati
> Priority: Minor
> Attachments: derby-304.diff
>
> If by mistake you give he location for the db backup as the db itself , then windows created directories recursively until it crashes!
> Repro:
> CallableStatement cs = conn.prepareCall("CALL SYSCS_UTIL.SYSCS_BACKUP_DATABASE_AND_ENABLE_LOG_ARCHIVE_MODE(?, ?)");
> cs.setString(1, "c:/maildb");
> cs.setInt(2, 1);
> cs.execute();
> cs.close();
> result:
> C:\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\..................... Until windows can not show the path!!!
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: [jira] Commented: (DERBY-304) If by mistake you give he location
for the db backup as the db itself , then windows created directories recursively
until windows crashes!
Posted by Suresh Thalamati <su...@gmail.com>.
Mike Matrigali wrote:
> Given the bad result at least in some environment it would be nice to
> catch whatever cases we can. Seems like comparing the paths either
> directly or using the absolute path mechanism is easy.
>
> The creating a file approach also looks like it is promising, i don't
> understand the overhead.
Overhead in create file approach is just searching though the datbase
directory to make sure the file we created is not threre ? May be
this little exta search does not really matter, considering backup is
I/O bound any way.
Thanks
-suresht
>
> Suresh Thalamati (JIRA) wrote:
>
>> [
>> http://issues.apache.org/jira/browse/DERBY-304?page=comments#action_12364909
>> ]
>> Suresh Thalamati commented on DERBY-304:
>> ----------------------------------------
>>
>> I tried the repro for this bug on my laptop with Windows XP , backup
>> failed while copying the directories., with the error:ERROR XSRS5:
>> Error copying file (during backup) from C:\maildb to c:\maildb\maildb.
>> OS did not crash for me..
>> I think it is very rare any user will make mistake of giving backup
>> path same as database home or one of its subdirectories. But I agree
>> it might be nice to throw a better error message, but that might add
>> some addtional restrictions or overhead.
>>
>> Some thought one possible way to fix this::
>>
>> 1) Get absolute paths for both the database home directory and the
>> backup directory then find if backup path is a subdirectory under
>> the database directory. Problem with this approach is :
>> a) Backup would always require read permission for
>> "user.dir" when run under security manager. b) If there are
>> symbolic links involved , this fix will not work.
>> 2) Add a counter to keep track how many level of deep the
>> directories are being created from the backup directory while doing
>> the copy. If the directory level is deeper than the database
>> normally has then throw error. This will work if user create
>> backup under <dbname>/jar or <dbname> but if the given backup path
>> is under "log" and "seg0" then we can not identify this case becuase
>> these directoties are not copied any more.
>>
>>
>> 3) At the start of the backup create a uniue file using a UUID
>> under the backup directory , then search for that file under the
>> database home directory. If that file is not found then one can be
>> sure backup path is not mapping to a subdirectiory of database
>> directory. Delete the new file created and then proceed with the
>> backup. I think this fix will work , but there is overhead of
>> searching through all the files under the database directory for a
>> error case.
>> 4) Don't bother to fix it , No one is going hit this problem again :-)
>>
>>
>> Any suggestions ?
>>
>>
>> Thanks
>> -suresht
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> If by mistake you give he location for the db backup as the db itself
>>> , then windows created directories recursively until windows crashes!
>>> -------------------------------------------------------------------------------------------------------------------------------------------
>>>
>>>
>>> Key: DERBY-304
>>> URL: http://issues.apache.org/jira/browse/DERBY-304
>>> Project: Derby
>>> Type: Bug
>>> Components: Store
>>> Versions: 10.1.1.0
>>> Environment: With JDK 142 on Windows XP
>>> Reporter: Manjula Kutty
>>> Priority: Minor
>>
>>
>>
>>> If by mistake you give he location for the db backup as the db itself
>>> , then windows created directories recursively until it crashes! Repro:
>>> CallableStatement cs = conn.prepareCall("CALL
>>> SYSCS_UTIL.SYSCS_BACKUP_DATABASE_AND_ENABLE_LOG_ARCHIVE_MODE(?, ?)");
>>> cs.setString(1, "c:/maildb");
>>> cs.setInt(2, 1);
>>> cs.execute();
>>> cs.close();
>>> result:
>>> C:\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\.....................
>>> Until windows can not show the path!!!
>>
>>
>>
>
>
Re: [jira] Commented: (DERBY-304) If by mistake you give he location
for the db backup as the db itself , then windows created directories recursively
until windows crashes!
Posted by Mike Matrigali <mi...@sbcglobal.net>.
Given the bad result at least in some environment it would be nice to
catch whatever cases we can. Seems like comparing the paths either
directly or using the absolute path mechanism is easy.
The creating a file approach also looks like it is promising, i don't
understand the overhead.
Suresh Thalamati (JIRA) wrote:
> [ http://issues.apache.org/jira/browse/DERBY-304?page=comments#action_12364909 ]
>
> Suresh Thalamati commented on DERBY-304:
> ----------------------------------------
>
> I tried the repro for this bug on my laptop with Windows XP , backup failed while copying the directories., with the error:ERROR XSRS5: Error copying file (during backup) from C:\maildb to c:\maildb\maildb.
> OS did not crash for me..
>
> I think it is very rare any user will make mistake of giving backup path same as database home or one of its subdirectories. But I agree it might be nice to throw a better error message, but that might add some addtional restrictions or overhead.
>
> Some thought one possible way to fix this::
>
> 1) Get absolute paths for both the database home directory and the backup directory then find if backup path is a subdirectory under the database directory. Problem with this approach is :
> a) Backup would always require read permission for "user.dir" when run under security manager.
> b) If there are symbolic links involved , this fix will not work.
>
> 2) Add a counter to keep track how many level of deep the directories are being created from the backup directory while doing the copy. If the directory level is deeper than the database normally has then throw error. This will work if user create backup under <dbname>/jar or <dbname> but if the given backup path is under "log" and "seg0" then we can not identify this case becuase these directoties are not copied any more.
>
>
> 3) At the start of the backup create a uniue file using a UUID under the backup directory , then search for that file under the database home directory. If that file is not found then one can be sure backup path is not mapping to a subdirectiory of database directory. Delete the new file created and then proceed with the backup. I think this fix will work , but there is overhead of searching through all the files under the database directory for a error case.
>
> 4) Don't bother to fix it , No one is going hit this problem again :-)
>
>
> Any suggestions ?
>
>
> Thanks
> -suresht
>
>
>
>
>
>
>
>
>
>
>
>
>>If by mistake you give he location for the db backup as the db itself , then windows created directories recursively until windows crashes!
>>-------------------------------------------------------------------------------------------------------------------------------------------
>>
>> Key: DERBY-304
>> URL: http://issues.apache.org/jira/browse/DERBY-304
>> Project: Derby
>> Type: Bug
>> Components: Store
>> Versions: 10.1.1.0
>> Environment: With JDK 142 on Windows XP
>> Reporter: Manjula Kutty
>> Priority: Minor
>
>
>>If by mistake you give he location for the db backup as the db itself , then windows created directories recursively until it crashes!
>>Repro:
>> CallableStatement cs = conn.prepareCall("CALL SYSCS_UTIL.SYSCS_BACKUP_DATABASE_AND_ENABLE_LOG_ARCHIVE_MODE(?, ?)");
>> cs.setString(1, "c:/maildb");
>> cs.setInt(2, 1);
>> cs.execute();
>> cs.close();
>>result:
>>C:\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\..................... Until windows can not show the path!!!
>
>
Re: [jira] Commented: (DERBY-304) If by mistake you give he location
for the db backup as the db itself , then windows created directories recursively
until windows crashes!
Posted by Mike Matrigali <mi...@sbcglobal.net>.
Good, I was thinking that your online backup changes had probably
changed the behavior of the recursive copy - maybe why you were seeing
the reported problem.
I think what you describe below plus the check that Dan suggested about
figuring out if the destination is a db is a reasonable error check for
bad user input in this case. Also it would be good to make sure the
documentation of the various procedures is clear about not backing up
the db into the db itself or another db.
As you say grant/revoke may eventually make sure only the right people
are executing the backup.
Suresh Thalamati wrote:
> Thanks Jeff, I agree with you, By making the list of all the contents of
> the database that need to go into the backup before creating backup
> directory will avoid the backup copying onto itself and going into end
> less recursion
>
> After my recent online backup changes, only the jar directory really
> uses recursive copy of directories because it has sub directories with
> schema names. One could just find the contents of this directory before
> creating the backup directory. And also just copy only files with "jar"
> suffix that are created by the database engine in the sub directories
> and ignore the user created files with any other extensions in these
> directories.
>
> I was hoping to find out some sure way to prevent users creating backup
> in the database directories, looks like there is not one without
> enforcing some special Security Permissions. Hopefully
> with GRANT/REVOKE feature , an administrator of the database can
> limit the users who can execute backup procedures.
>
>
> Thanks
> -surest
>
> Jeffrey Lichtman wrote:
>
>> I haven't been following this thread very closely, so please forgive
>> me if this has already been considered. I assume the problem is that
>> the backup algorithm creates a directory to contain the backup, so if
>> the location of the backup is in the database it tries to copy the
>> contents of the backup into itself.
>>
>> Would it work to make a list of the contents of the database before
>> creating the backup directory, and then make the algorithm work off
>> the list? I suppose it would be better to keep the user from putting
>> the backup in the database, but that isn't always easy to prevent.
>>
>>
>> - Jeff Lichtman
>> swazoo@rcn.com
>> Check out Swazoo Koolak's Web Jukebox at
>> http://swazoo.com/
>>
>
>
Re: [jira] Commented: (DERBY-304) If by mistake you give he location
for the db backup as the db itself , then windows created directories recursively
until windows crashes!
Posted by Suresh Thalamati <su...@gmail.com>.
Thanks Jeff, I agree with you, By making the list of all the contents
of the database that need to go into the backup before creating backup
directory will avoid the backup copying onto itself and going into
end less recursion
After my recent online backup changes, only the jar directory really
uses recursive copy of directories because it has sub directories with
schema names. One could just find the contents of this directory
before creating the backup directory. And also just copy only files
with "jar" suffix that are created by the database engine in the sub
directories and ignore the user created files with any other
extensions in these directories.
I was hoping to find out some sure way to prevent users creating
backup in the database directories, looks like there is not one
without enforcing some special Security Permissions. Hopefully
with GRANT/REVOKE feature , an administrator of the database can
limit the users who can execute backup procedures.
Thanks
-surest
Jeffrey Lichtman wrote:
> I haven't been following this thread very closely, so please forgive me
> if this has already been considered. I assume the problem is that the
> backup algorithm creates a directory to contain the backup, so if the
> location of the backup is in the database it tries to copy the contents
> of the backup into itself.
>
> Would it work to make a list of the contents of the database before
> creating the backup directory, and then make the algorithm work off the
> list? I suppose it would be better to keep the user from putting the
> backup in the database, but that isn't always easy to prevent.
>
>
> - Jeff Lichtman
> swazoo@rcn.com
> Check out Swazoo Koolak's Web Jukebox at
> http://swazoo.com/
>
Re: [jira] Commented: (DERBY-304) If by mistake you give he
location for the db backup as the db itself , then windows created
directories recursively until windows crashes!
Posted by Jeffrey Lichtman <sw...@rcn.com>.
I haven't been following this thread very closely, so please forgive
me if this has already been considered. I assume the problem is that
the backup algorithm creates a directory to contain the backup, so if
the location of the backup is in the database it tries to copy the
contents of the backup into itself.
Would it work to make a list of the contents of the database before
creating the backup directory, and then make the algorithm work off
the list? I suppose it would be better to keep the user from putting
the backup in the database, but that isn't always easy to prevent.
- Jeff Lichtman
swazoo@rcn.com
Check out Swazoo Koolak's Web Jukebox at
http://swazoo.com/
Re: [jira] Commented: (DERBY-304) If by mistake you give he location
for the db backup as the db itself , then windows created directories recursively
until windows crashes!
Posted by Suresh Thalamati <su...@gmail.com>.
Daniel John Debrunner wrote:
> Would this fix address creating a backup of running database A over
> running database B by accident? It seems to assume there is only one
> database around.
You are right, creating file in the backup path and checking for it in
the dbhome will not find if backup path is referring to another
database directory.
>
> One thought I had was for the backup code not to allow a backup at C if
> the file C/service.properties exists. May not solve every problem but
> would remove some opportunities for a backupto overwrite a running database.
I agree with you, this will avoid at least some cases. One case this
approach will not work is if some one attempts to create backup under
the subdirectories of database home, I guess that is ok. I will
submit a patch with approach.
>
> Another possible longer-term solution, at least with the security
> manager, would be to add some Derby specific permissions for backup,
> import and export. Haven't put much thought into how this would work and
> how it would affect backward compat.
>
Sound like a good idea, for short term I will fix it by checking for
service.properties, it will be useful if some one is running without
security manager enabled.
Thanks
-suresht
>
> Dan.
>
>
> Suresh Thalamati wrote:
>
>
>>Thanks Bryan. I was also thinking on the similar lines on the possible
>>fixes(#3) I mentioned in my comments. This seems to better idea
>>than trying to deal with paths/permissions.
>>
>>-suresh
>>
>>Bryan Pendleton wrote:
>>
>>
>>>>I think it is very rare any user will make mistake of giving
>>>>backup path same as database home or one of its subdirectories. But I
>>>>agree it might be nice to throw a better error message, but that
>>>>might add some addtional restrictions or overhead.
>>>>
>>>>Some thought one possible way to fix this::
>>>
>>>
>>>
>>>Here's an idea:
>>>
>>> Store a file with an obvious name into the backup path.
>>>
>>> Then search down from the database home and see if you find the file.
>>>
>>> If you do, there's an error. If you don't, things are fine.
>>>
>>> Either way, remove the file once you're done.
>>>
>>>I don't believe this requires any additional security permissions,
>>>because
>>>you already have to be able to write to the backup and read from the
>>>database in order to perform the backup.
>>>
>>>And I think this algorithm is pretty reliable in the face of symbolic
>>>links,
>>>etc., because you are working with a real file in a real location, not
>>>trying to interpret the paths abstractly.
>>>
>>>Just thought I'd throw this out there, in case it gave you some ideas
>>>of ways to work on the problem.
>
>
>
>
Re: [jira] Commented: (DERBY-304) If by mistake you give he location
for the db backup as the db itself , then windows created directories recursively
until windows crashes!
Posted by Daniel John Debrunner <dj...@apache.org>.
Would this fix address creating a backup of running database A over
running database B by accident? It seems to assume there is only one
database around.
One thought I had was for the backup code not to allow a backup at C if
the file C/service.properties exists. May not solve every problem but
would remove some opportunities for a backupto overwrite a running database.
Another possible longer-term solution, at least with the security
manager, would be to add some Derby specific permissions for backup,
import and export. Haven't put much thought into how this would work and
how it would affect backward compat.
Dan.
Suresh Thalamati wrote:
> Thanks Bryan. I was also thinking on the similar lines on the possible
> fixes(#3) I mentioned in my comments. This seems to better idea
> than trying to deal with paths/permissions.
>
> -suresh
>
> Bryan Pendleton wrote:
>
>>> I think it is very rare any user will make mistake of giving
>>> backup path same as database home or one of its subdirectories. But I
>>> agree it might be nice to throw a better error message, but that
>>> might add some addtional restrictions or overhead.
>>>
>>> Some thought one possible way to fix this::
>>
>>
>>
>> Here's an idea:
>>
>> Store a file with an obvious name into the backup path.
>>
>> Then search down from the database home and see if you find the file.
>>
>> If you do, there's an error. If you don't, things are fine.
>>
>> Either way, remove the file once you're done.
>>
>> I don't believe this requires any additional security permissions,
>> because
>> you already have to be able to write to the backup and read from the
>> database in order to perform the backup.
>>
>> And I think this algorithm is pretty reliable in the face of symbolic
>> links,
>> etc., because you are working with a real file in a real location, not
>> trying to interpret the paths abstractly.
>>
>> Just thought I'd throw this out there, in case it gave you some ideas
>> of ways to work on the problem.
Re: [jira] Commented: (DERBY-304) If by mistake you give he location
for the db backup as the db itself , then windows created directories recursively
until windows crashes!
Posted by Suresh Thalamati <su...@gmail.com>.
Thanks Bryan. I was also thinking on the similar lines on the possible
fixes(#3) I mentioned in my comments. This seems to better idea
than trying to deal with paths/permissions.
-suresh
Bryan Pendleton wrote:
>> I think it is very rare any user will make mistake of giving backup
>> path same as database home or one of its subdirectories. But I agree
>> it might be nice to throw a better error message, but that might add
>> some addtional restrictions or overhead.
>>
>> Some thought one possible way to fix this::
>
>
> Here's an idea:
>
> Store a file with an obvious name into the backup path.
>
> Then search down from the database home and see if you find the file.
>
> If you do, there's an error. If you don't, things are fine.
>
> Either way, remove the file once you're done.
>
> I don't believe this requires any additional security permissions, because
> you already have to be able to write to the backup and read from the
> database in order to perform the backup.
>
> And I think this algorithm is pretty reliable in the face of symbolic
> links,
> etc., because you are working with a real file in a real location, not
> trying to interpret the paths abstractly.
>
> Just thought I'd throw this out there, in case it gave you some ideas
> of ways to work on the problem.
>
> thanks,
>
> bryan
>
>
Re: [jira] Commented: (DERBY-304) If by mistake you give he location
for the db backup as the db itself , then windows created directories recursively
until windows crashes!
Posted by Bryan Pendleton <bp...@amberpoint.com>.
> I think it is very rare any user will make mistake of giving backup path same as database home or one of its subdirectories. But I agree it might be nice to throw a better error message, but that might add some addtional restrictions or overhead.
>
> Some thought one possible way to fix this::
Here's an idea:
Store a file with an obvious name into the backup path.
Then search down from the database home and see if you find the file.
If you do, there's an error. If you don't, things are fine.
Either way, remove the file once you're done.
I don't believe this requires any additional security permissions, because
you already have to be able to write to the backup and read from the
database in order to perform the backup.
And I think this algorithm is pretty reliable in the face of symbolic links,
etc., because you are working with a real file in a real location, not
trying to interpret the paths abstractly.
Just thought I'd throw this out there, in case it gave you some ideas
of ways to work on the problem.
thanks,
bryan
[jira] Commented: (DERBY-304) If by mistake you give he location
for the db backup as the db itself , then windows created directories
recursively until windows crashes!
Posted by "Suresh Thalamati (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-304?page=comments#action_12364909 ]
Suresh Thalamati commented on DERBY-304:
----------------------------------------
I tried the repro for this bug on my laptop with Windows XP , backup failed while copying the directories., with the error:ERROR XSRS5: Error copying file (during backup) from C:\maildb to c:\maildb\maildb.
OS did not crash for me..
I think it is very rare any user will make mistake of giving backup path same as database home or one of its subdirectories. But I agree it might be nice to throw a better error message, but that might add some addtional restrictions or overhead.
Some thought one possible way to fix this::
1) Get absolute paths for both the database home directory and the backup directory then find if backup path is a subdirectory under the database directory. Problem with this approach is :
a) Backup would always require read permission for "user.dir" when run under security manager.
b) If there are symbolic links involved , this fix will not work.
2) Add a counter to keep track how many level of deep the directories are being created from the backup directory while doing the copy. If the directory level is deeper than the database normally has then throw error. This will work if user create backup under <dbname>/jar or <dbname> but if the given backup path is under "log" and "seg0" then we can not identify this case becuase these directoties are not copied any more.
3) At the start of the backup create a uniue file using a UUID under the backup directory , then search for that file under the database home directory. If that file is not found then one can be sure backup path is not mapping to a subdirectiory of database directory. Delete the new file created and then proceed with the backup. I think this fix will work , but there is overhead of searching through all the files under the database directory for a error case.
4) Don't bother to fix it , No one is going hit this problem again :-)
Any suggestions ?
Thanks
-suresht
> If by mistake you give he location for the db backup as the db itself , then windows created directories recursively until windows crashes!
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-304
> URL: http://issues.apache.org/jira/browse/DERBY-304
> Project: Derby
> Type: Bug
> Components: Store
> Versions: 10.1.1.0
> Environment: With JDK 142 on Windows XP
> Reporter: Manjula Kutty
> Priority: Minor
>
> If by mistake you give he location for the db backup as the db itself , then windows created directories recursively until it crashes!
> Repro:
> CallableStatement cs = conn.prepareCall("CALL SYSCS_UTIL.SYSCS_BACKUP_DATABASE_AND_ENABLE_LOG_ARCHIVE_MODE(?, ?)");
> cs.setString(1, "c:/maildb");
> cs.setInt(2, 1);
> cs.execute();
> cs.close();
> result:
> C:\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\maildb\..................... Until windows can not show the path!!!
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira