linux_masked_paths integration test #2950
Conversation
nayuta-ai
force-pushed
the
integration_test/linux_masked_paths
branch
from
063d558
to
6d0604c
Compare
tests/contest/contest/src/tests/linux_masked_paths/masked_paths.rs
Outdated
Show resolved
Hide resolved
nayuta-ai
force-pushed
the
integration_test/linux_masked_paths
branch
from
52b4683
to
448504e
Compare
|
@utam0k Thank you for the review! Please review my code again. |
nayuta-ai
force-pushed
the
integration_test/linux_masked_paths
branch
from
d3600be
to
62e5e1a
Compare
nayuta-ai
force-pushed
the
integration_test/linux_masked_paths
branch
4 times, most recently
from
7fa807b
to
2baa120
Compare
Hey, thanks a lot, I'll try to get to this today or so. |
tests/contest/contest/src/tests/linux_masked_paths/masked_paths.rs
Outdated
Show resolved
Hide resolved
| match fs::metadata(&test_file) { | ||
| io::Result::Ok(md) => { | ||
| bail!( | ||
| "reading path {:?} should have given error, found {:?} instead", | ||
| test_file, | ||
| md | ||
| ) | ||
| } | ||
| io::Result::Err(e) => { | ||
| let err = e.kind(); | ||
| if let io::ErrorKind::NotFound = err { | ||
| Ok(()) | ||
| } else { | ||
| bail!("expected not found error, got {:?}", err); | ||
| } | ||
| } | ||
| } | ||
| }) |
There was a problem hiding this comment.
Why is this check here? we should be checking this in the runtime test and here we should be creating the path, right? Or did I misunderstood anything?
There was a problem hiding this comment.
When setting a masked path, it is impossible to determine whether it is a relative path, so I added this to verify whether it meets the test requirements at the time of creation. This implementation is also adopted in runtime-tools, so verification is necessary.
There was a problem hiding this comment.
ok, so I see that you have carried over the implementation from go tests, but I'm still having a bit of difficulty understanding this -
- The go code seems to checks that if error is not null and error is not found, then return error, else return null. I.e. if the error is not found, then the prepare function will return error, other wise not. Here the behavior seems to be opposite.
- Also, this function/closure we pass, both here and in go code, will be executed before runtime has done anything. This is supposed to prepare the rootfs for tests running inside the container. Given that, what exactly is this checking? This will be running on plain bundle fs that is created for each test, It is ofcourse not going to find any of the files.
What I'm thinking here is that even the go tests have slightly incorrect implementation (which has happened before). Can you confirm going through comments in go code and seeing what the test is supposed to check, and what it is actually validating?
There was a problem hiding this comment.
There are cases where the Go implementation may be incorrect. I'll check it out.
There was a problem hiding this comment.
I posted a question in the Issue because I couldn’t fully grasp the purpose of this test.（opencontainers/runtime-tools#780 ）
This is my own opinion, but I believe the test might be trying to illustrate a discrepancy where the path added to masked_path is specified from the host system’s perspective, resulting in an unintended relative path from / inside the container that doesn’t match the expected path.
As for addressing this test, we could:
- Add the above comment
- Wait for a response on the Issue before deciding
- Delete the test
- Refactor the test
If we choose to improve the test, I think the following approach could work:
- Create a file inside the container we want to mask (
masked-relpath). - Specify the relative path from the host system (
./bundle/rootfs/masked-relpath) as the path to mask. - After creating the container, verify that the file is masked by checking if it exists at the expected path without the
./bundle/rootfsprefix.
Do you think this would be a good approach?
There was a problem hiding this comment.
As stated in the runtime-spec, setting a relative path is not allowed. Therefore, I believe the correct responsibility of contest is to produce an error when a relative path is set during testing. Based on this, I implemented the following.
c471733
Regarding runtimetest, I made it verify that paths passed to the namespace are not relative path to ensure the behavior complies with the runtime-spec.
One concern is whether to add an implementation to validate relative_path in the spec's validation. This would also affect the test behavior, so I am leaving this comment for discussion.
https://github.com/youki-dev/youki/blob/main/crates/libcontainer/src/container/init_builder.rs#L152
BTW, in runc, validation to ensure masked_path is an absolute path is not performed, so it might not be necessary.
tests/contest/contest/src/tests/linux_masked_paths/masked_paths.rs
Outdated
Show resolved
Hide resolved
tests/contest/contest/src/tests/linux_masked_paths/masked_paths.rs
Outdated
Show resolved
Hide resolved
|
@nayuta-ai , I have replied to comments, also the PR has conflicts with main, Please make the suggested changes and resolve conflicts. Thanks. |
nayuta-ai
force-pushed
the
integration_test/linux_masked_paths
branch
2 times, most recently
from
48739f7
to
8ec531f
Compare
Signed-off-by: nayuta-ai <[email protected]>
…s.rs Signed-off-by: nayuta-ai <[email protected]>
Signed-off-by: nayuta-ai <[email protected]>
Signed-off-by: nayuta-ai <[email protected]>
Signed-off-by: nayuta-ai <[email protected]>
Signed-off-by: nayuta-ai <[email protected]>
nayuta-ai
force-pushed
the
integration_test/linux_masked_paths
branch
from
e95796f
to
5ceb009
Compare
nayuta-ai
force-pushed
the
integration_test/linux_masked_paths
branch
from
5ceb009
to
d1fa11b
Compare
|
@YJDoc2 |
Signed-off-by: nayuta-ai <[email protected]>
nayuta-ai
force-pushed
the
integration_test/linux_masked_paths
branch
from
d1fa11b
to
c471733
Compare
Summary
Create linux_masked_paths integration test.
Related Issue
#361
Refer