Repository navigation
fix(solid): never count a user's storage as an instance's own folder - #734
Merged
Merged
Conversation
An older deck document that does not say it is the deck's is taken as the deck's in the instance's own folder: the next write states it, the data check does not list it, and a removal deletes it without reading it. A pod's or a storage's root is never such a folder, as it holds the user's other data too. But the guard knew a storage's root only when the server typed it, and a server that holds many users' pods on one origin may leave their roots untyped. An instance kept at the root of the user's pod there took every older document in the pod for the deck's, though the user's profile names that folder as a storage. The instance's folder is now not its own when it is one of the user's storages or a folder above one, whatever the case of the host, its default port or a trailing slash, as well as when the server shows it as a storage's root. When the user's storages can't be found, a write fails and can be retried, and the data check and a removal read the document and take it for unclaimed unless it says it is the deck's. Refs: GHSA-pq2f-cr8r-9jqc
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.
What and why
An older deck document that doesn't say it is the deck's is taken as the deck's when it sits in the instance's own folder. The next write then adds its back-link, the data check doesn't list it, and a removal deletes it without reading it. A pod's or a storage's root is never such a folder, because it holds the user's other data too.
The guard only recognized a storage root when the server typed it as one. Some servers hold many users' pods on one origin and leave their roots untyped. On those, an instance kept at the root of the user's pod treated every older document in the pod as the deck's, even though the user's profile names that folder as a storage.
What changes:
docs/data-model.mdsays how a pod or storage root is recognized. This builds on the user's storages that the previous storage fix (#730) passes to the guard.Refs: GHSA-pq2f-cr8r-9jqc