db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suresh Thalamati <suresh.thalam...@gmail.com>
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 Tue, 07 Feb 2006 01:11:37 GMT
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.
> 
> 
> 
> 


Mime
View raw message