RCORE-2070 Allow setting a security access group for the metadata realm keychain #7552
Conversation
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
tgoyne
force-pushed
the
tg/keychain-access-group
branch
3 times, most recently
from
14d9da7 to
aac009b
Compare
Pull Request Test Coverage Report for Build thomas.goyne_273Details
💛 - Coveralls |
tgoyne
force-pushed
the
tg/keychain-access-group
branch
from
aac009b to
d435b58
Compare
nirinchev
reviewed
Apr 4, 2024
tgoyne
force-pushed
the
tg/keychain-access-group
branch
from
d435b58 to
20846ee
Compare
ironage
approved these changes
Apr 8, 2024
Contributor
ironage
left a comment
ironage
left a comment
There was a problem hiding this comment.
I'm not an expert in this area, but it looks fine to me. I also take confidence from the legacy migration test. 👍
Access groups are shared storage for one or more apps on iOS (and other Apple platforms). Sharing a metadata Realm between apps requires placing the file in the access group storage and storing the encryption key in the access group's keychain. Including the bundle ID in the service name breaks sharing the key between apps, as different apps will have different bundle IDs. For everything but un-sandboxed macOS there wasn't actually any reason to include the bundle ID in the first place, as each app has its own keychain anyway. As such, this switches back to not including it. On macOS this continues to include the bundle ID when not using an access group, as otherwise different applications could conflict with each other. This means that sharing users between macOS applications will currently only work if an encryption key is explicitly set or if the applications have sandboxing enabled. Since this is slightly changing how keys are stored anyway, it also switches to using unique keys per server app ID rather than always using "metadata" as the account name. The keychain code was mostly multiprocess-safe, but there was one race condition when two apps generated a new key at once which is fixed.
tgoyne
force-pushed
the
tg/keychain-access-group
branch
from
20846ee to
13f3b91
Compare
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Access groups are shared storage for one or more apps on iOS (and other Apple platforms). Sharing a metadata Realm between apps requires placing the file in the access group storage and storing the encryption key in the access group's keychain.
Including the bundle ID in the service name breaks sharing the key between apps, as different apps will have different bundle IDs. For everything but un-sandboxed macOS there wasn't actually any reason to include the bundle ID in the first place, as each app has its own keychain anyway. As such, this switches back to not including it. On macOS this continues to include the bundle ID when not using an access group, as otherwise different applications could conflict with each other. This means that sharing users between macOS applications will currently only work if an encryption key is explicitly set or if the applications have sandboxing enabled.
Since this is slightly changing how keys are stored anyway, it also switches to using unique keys per server app ID rather than always using "metadata" as the account name.
The keychain code was mostly multiprocess-safe, but there was one race condition when two apps generated a new key at once which is fixed.