-
Notifications
You must be signed in to change notification settings - Fork 238
Locking unpacked files #171
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Codecov Report
@@ Coverage Diff @@
## master #171 +/- ##
==========================================
+ Coverage 95.73% 95.75% +0.01%
==========================================
Files 311 312 +1
Lines 15498 15586 +88
==========================================
+ Hits 14837 14924 +87
- Misses 661 662 +1
Continue to review full report at Codecov.
|
jstucke
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the database with the locks should be dropped at startup to prevent undeletable artifacts of cancelled or crashed analyses
src/test/common_helper.py
Outdated
| return uid in self.locks | ||
|
|
||
| def release_unpacking_lock(self, uid): | ||
| self.locks.remove(uid) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
function is unused
|
|
||
| def test_file_is_locked(self): | ||
| assert not self.unpacker.db_interface.check_unpacking_lock(self.test_fo.uid) | ||
| file_pathes = ['{}/get_files_test/testfile1'.format(get_test_data_dir())] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
typo
Problem of race condition has appeared since binary deletion was activated recently.
Whenever a firmware is deleted, issuing a cascade of file deletions, a new analysis can overlap with the files. Then a file can be extracted during analysis, deleted shortly after due to the firmware deletion, and analyzed later on at which point the file has been deleted.
This happens basically every time a re-do anlysis is issued, but can happen in other scenarios as well.
A locking of extracted files should prevent that from happening. That is:
As of now, if a deletion request is issued in between steps 3 and 5, the file is remove as no database link exists to it. Once step 5 is processed, a new link in the database exists and the lock can be safely removed. As long as the lock is in place, any deletion attempt will be discarded.