-
Notifications
You must be signed in to change notification settings - Fork 165
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
Fix more encryption issues on exFAT filesystem #7162
Conversation
…t for new Realms leading to corruption for encrypted Realms
Pull Request Test Coverage Report for Build james.stone_440
💛 - Coveralls |
…ave the same fallback tmp path which could cause issues if running on a filesystem that doesn't support mkfifo such as exFAT
Ping for reviews @finnschiermer @kiburtse @tgoyne |
asserting in consideration of external processes. Use prealloc to size the file instead of a separate resize operation. Add the file path to help debug exceptions.
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.
Very nice! :-D
Was encryption a feature of the 1.0.0 Realm Core release? |
@kraenhansen yes, there was encryption in v1.0.0 and I'm fairly certain the bug was present there because we had the static |
Fixes #7156
The issues here can be reproduced by running the core tests on an exFAT file system. See
tools/run-tests-on-exfat.sh
Specifically, opening several new encrypted Realms at the same time in the same process. For example, I used
UNITTEST_FILTER=*_EncryptionKey*
andUNITTEST_REPEAT=1000
to reliably debug this.The issue is the same underlying issue as described in #6959 where the exFAT file system does not actually reserve the inode until the file is non-empty. The effect of having the unique id reused across multiple files in this case is that the static mappings_by_file structure merges encrypted mappings across different files. This can lead to data from one file ending up in the other, and general corruption.
In addition to fixing the issue, and cleaning up the surrounding code a bit, I have added an assertion in the
File::get_unique_id()
method to check that it is called on a non-empty file so that we don't hit this bug again.☑️ ToDos
bindgen/spec.yml
, if public C++ API changed