#10868: _destroy_test_db exposes the production database to possibly destructive
actions from the unit tests
-------------------------------------+-------------------------------------
Reporter: ovidiu | Owner: nobody
Type: Bug | Status: new
Component: Testing framework | Version:
Severity: Release blocker | Resolution:
Keywords: django.test | Triage Stage: Design
Has patch: 0 | decision needed
Needs tests: 0 | Needs documentation: 0
Easy pickings: 0 | Patch needs improvement: 0
| UI/UX: 0
-------------------------------------+-------------------------------------
Changes (by akaariai):
* ui_ux: => 0
* easy: => 0
Comment:
The problem here is that the settings_dict is shared between threads. This
means that after `self.connection.settings_dict['NAME'] =
old_database_name` (line 323 in creation.py) every new connection taken by
different threads will access the production database, not the test
database. I don't know how likely this is to happen. You would need a
thread taking a _new_ connection.
For potential fixes: on line 323, do a copy of the settings dict, then set
the old database name. self.connection is threading.local subclass, so if
the settings_dict is copied, the change affects only current thread (the
one doing the drop database). Changing directly the settings dict will do
the change for every thread, as the passed in settings_dict is the same
instance for every thread. But I think Django does want to restore the
environment to the previous state after tests have ran, and thus, if a
thread wakes up at a later point (after the test db has been dropped) and
takes a new connection, it will be directed to the production database. So
3 more solutions:
- Do not restore the environment
- The user should make sure the threads he has created are not running
after the test suite is completed (in other words, mark as wont fix).
- Check alive threads before dropping the test database. If there are
more alive threads than the main thread, bail out. I think this is safest
way to go forward. Anyways you should not have any test threads running
after the test suite has completed. You would possibly want to check the
running thread names before tests, and after test and see that they match,
so that if there are threads running in the background before the test,
you would still be able to run tests.
--
Ticket URL: <https://code.djangoproject.com/ticket/10868#comment:3>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en.
