More validation #319
Merged
More validation #319
Conversation
This file contains 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
cgwalters
force-pushed
the
more-validation
branch
from
6a4e71f
to
b8e629e
Compare
This one previously ended up with a NULL pointer deference in the bowels of the EROFS generation. Signed-off-by: Colin Walters <walters@verbum.org>
There's no good reason for us to support this; we should expect paths to be canonicalized. In theory we *could* handle this, but I am doubtful anyone actually relies on it. In EROFS these are supposed to be "hard links" to the relevant directories; the EROFS generation adds them if they don't exist. I tried to do stronger validation at the `lcfs_node_*` level but that is trickier. Let's just reject at the dump file for now. Signed-off-by: Colin Walters <walters@verbum.org>
Hooray! We were actually validating this already. Just another corner case I thought of. Signed-off-by: Colin Walters <walters@verbum.org>
While we have a check in `mkcomposefs.c`, let's also have one at the C API level because we want to guard against misuse/attack from something directly operating on that API. Signed-off-by: Colin Walters <walters@verbum.org>
Matching the C side, but we want to detect errors where we can early on the Rust side here too as it's safer. - Also verify path length here - Deny hardlinked directories - And canonicalize and enforce normal form for paths Signed-off-by: Colin Walters <walters@verbum.org>
cgwalters
force-pushed
the
more-validation
branch
from
b8e629e
to
a6b0a65
Compare
alexlarsson
approved these changes
Aug 20, 2024
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.
mkcomposefs: Fail on an empty symlink target
This one previously ended up with a NULL pointer deference
in the bowels of the EROFS generation.
Signed-off-by: Colin Walters walters@verbum.org
mkcomposefs: Reject
.and..in pathsThere's no good reason for us to support this; we should
expect paths to be canonicalized. In theory we could handle
this, but I am doubtful anyone actually relies on it.
In EROFS these are supposed to be "hard links" to the relevant
directories; the EROFS generation adds them if they don't
exist. I tried to do stronger validation at the
lcfs_node_*level but that is trickier.
Let's just reject at the dump file for now.
Signed-off-by: Colin Walters walters@verbum.org
tests: Add a test case that directories can't be hardlinked
Hooray! We were actually validating this already. Just
another corner case I thought of.
Signed-off-by: Colin Walters walters@verbum.org
writer: Also check for dir hardlinks when canonicalizing tree
While we have a check in
mkcomposefs.c, let's also have oneat the C API level because we want to guard against misuse/attack
from something directly operating on that API.
Signed-off-by: Colin Walters walters@verbum.org
rust/dumpfile: More validation
Signed-off-by: Colin Walters walters@verbum.org