Open
Conversation
b96dec5 to
92a8019
Compare
92a8019 to
a18be15
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
It is not clear what the problem with Ubuntu Touch was that caused this, but the changes make accounts.toml sync safer in any case. There are other operating systems and possibly incorrect fdatasync() implementations, it is safer to just always use fsync(). This PR also syncs the rename().
There was a report that on Ubuntu Touch with
fscrypt-encrypted filesystem, accounts.toml turned into a file with random contents.Reading on
fscrypt, it says each file has its own "nonce" which protects the file:https://www.kernel.org/doc/html/v6.19/filesystems/fscrypt.html#per-file-encryption-keys
It is not clear if nonce is part of the "metadata" synced with fsync on the file handle. Also this does not explain why filename did not get corrupted, but only the bytes. Filenames in fscrypt are kind of special because they are also part of the directory, so it is still possible that it is fscrypt problem: https://www.kernel.org/doc/html/v6.19/filesystems/fscrypt.html#filenames-encryption
UBPorts documentation for fscrypt is at https://docs.ubports.com/en/latest/porting/configure_test_fix/Fscrypt.html
It could be that contents was corrupted because of use-after-free that is fixed with #7962
Account manager got freed and its memory was reused.
The file though looks entirely random. Does not have zero bytes, one 0xff, one 0x01, three 0x02, two 0x03, ..., two 0xd7, one 0xd8, two 0xd9 etc.