test(jailer): regression test for chroot bind-mount propagation#5939
test(jailer): regression test for chroot bind-mount propagation#5939xxgj wants to merge 1 commit into
Conversation
not4s
left a comment
There was a problem hiding this comment.
Thanks for contributing! Would you mind rebasing onto main and dropping the merge commit? I've also left a few comments and would love to hear your thoughts.
Apologies for the misclick. Rebased onto latest main and it should be a single commit now.
Thanks for the review! Comments are replied above and let me know if you would like to discuss further:) |
Codecov Report✅ All modified and coverable lines are covered by tests. Please upload reports for the commit 41bdb86 to get more accurate results. Additional details and impacted files@@ Coverage Diff @@
## main #5939 +/- ##
=======================================
Coverage 82.99% 83.00%
=======================================
Files 277 277
Lines 30121 30132 +11
=======================================
+ Hits 24998 25010 +12
+ Misses 5123 5122 -1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
This comment was marked as resolved.
This comment was marked as resolved.
|
No worries at all! Rebased and got the DCO check passing. Thanks again for your time and effort :) |
Bind mounts established on the host inside the chroot before jailer start must propagate into the jailer's mount namespace. The test bind-mounts kernel and rootfs onto empty placeholders in the chroot and drives the API directly (bypassing basic_config to avoid create_jailed_resource hardlinking over the mounts), then asserts a clean SSH boot. Signed-off-by: Junren Chen <xxgj@outlook.com>
|
Hi @not4s , Sorry for the back-and-forth :( It seems the rebase commit may have invalidated your prior approval, so this might need another look.. It also appears two approvals are required, should I request a second reviewer? |
Changes
Bind mounts established on the host inside the chroot before jailer start must propagate into the jailer's mount namespace. The test bind-mounts kernel and rootfs onto empty placeholders in the chroot and drives the API directly (bypassing basic_config to avoid create_jailed_resource hardlinking over the mounts), then asserts a clean SSH boot.
Tests
Successful run
Reproduce #1089
Step 1. Revert the fix locally to restore the buggy behavior
Step 2. Run the test
The 400 response and "Unable to read elf header" message match #1089 (comment) , confirming the test reproduces the original bug when the fix is reverted.
Reason
Closes #1099
License Acceptance
By submitting this pull request, I confirm that my contribution is made under
the terms of the Apache 2.0 license. For more information on following Developer
Certificate of Origin and signing off your commits, please check
CONTRIBUTING.md.PR Checklist
tools/devtool checkbuild --allto verify that the PR passesbuild checks on all supported architectures.
tools/devtool checkstyleto verify that the PR passes theautomated style checks.
how they are solving the problem in a clear and encompassing way.
in the PR.
CHANGELOG.md.Runbook for Firecracker API changes.
integration tests.
TODO.rust-vmm.