db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject 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!
Date Mon, 06 Feb 2006 22:29:03 GMT

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.



Mime
View raw message