fix(3207, 3209) Difference between the exec command in runc and youki

[tommady]

Description

Type of Change

• Bug fix (non-breaking change that fixes an issue)
• New feature (non-breaking change that adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Refactoring (no functional changes)
• Performance improvement
• Test updates
• CI/CD related changes
• Other (please describe):

Testing

• Added new unit tests
• Added new integration tests
• Ran existing test suite
• Tested manually (please provide steps)

Related Issues

Fixes #3207 #3209

Additional Context

[saku3]

I haven’t been able to review everything yet, but I did check the cgroup-related parts.

I’m not sure whether the deletion logic works correctly when a sub-cgroup is created.

$ youki  run -b tutorial container

another terminal

$ youki exec container sh -euc "mkdir /sys/fs/cgroup/foobar && echo 1 > /sys/fs/cgroup/foobar/cgroup.procs && grep -w foobar /proc/1/cgroup"

the original terminal

$ exit
ERROR libcontainer::container::container_delete: failed to remove cgroup due to: V2(WrappedIo(Other { err: Custom { kind: TimedOut, error: "could not delete" }, path: "/sys/fs/cgroup/:youki:container" })) cgroup_path=":youki:container"
ERROR youki: error in executing command: io error: at /sys/fs/cgroup/:youki:container: could not delete

Caused by:
    at /sys/fs/cgroup/:youki:container: could not delete
run failed : io error: at /sys/fs/cgroup/:youki:container: could not delete

[saku3]

Ideally, the following test cases should exist.

• Now move init to a subcgroup, and check it was moved.

youki exec a sh -euc "mkdir /sys/fs/cgroup/foobar && echo 1 > /sys/fs/cgroup/foobar/cgroup.procs && grep -w foobar /proc/1/cgroup"

• The init process is now in "/foo", but an exec process can still join "/" because we haven't enabled any domain controller yet.

 youki exec a grep '^0::/$' /proc/self/cgroup

• Turn on a domain controller (memory).

 youki exec a sh -euc 'echo $$ > /sys/fs/cgroup/foobar/cgroup.procs; echo +memory > /sys/fs/cgroup/cgroup.subtree_control'

• An exec process can no longer join "/" after turning on a domain controller. Check that cgroup v2 fallback to init cgroup works.
  • This command is expected to succeed.

 youki exec a sh -euc "cat /proc/self/cgroup && grep '^0::/foobar$' /proc/self/cgroup"

• Check that --cgroup / disables the init cgroup fallback.
  • This command is expected to fail.

youki exec --cgroup / a true

• Check that explicit --cgroup foobar works.

youki exec --cgroup foobar a grep '^0::/foobar$' /proc/self/cgroup

• Check all processes is in foobar (this check is redundant).

youki exec --cgroup foobar a sh -euc '! grep -vwH foobar /proc/*/cgroup'

• Add a second subcgroup, check we're in it.

youki exec --cgroup foobar a mkdir /sys/fs/cgroup/second
youki exec --cgroup second a grep -w second /proc/self/cgroup

[tommady]

The changes in #3347 will help address and enhance the testcase requested by saku3.

Just a memo for myself — turning this PR back to draft.

[saku3]

@tommady
I haven’t had much time to review this PR recently — sorry about that.

For this PR, if we can’t move it forward until issue #3347 is resolved, I think we could proceed by leaving TODO comments (or create sub-issue) for the parts related to #3347 for now.

What approach would be easiest for you to proceed?

[tommady]

@tommady I haven’t had much time to review this PR recently — sorry about that.

For this PR, if we can’t move it forward until issue #3347 is resolved, I think we could proceed by leaving TODO comments (or create sub-issue) for the parts related to #3347 for now.

What approach would be easiest for you to proceed?

Thanks for the suggestion!

From my point of view, this PR is ready for review.
Aside from the parts related to issue #3347, there was also an earlier comment from you:
#3210 (comment)

Because of that, some of the cgroup tests can’t be implemented right now.

So yes, please review it when you have time 🙂

[saku3]

Thank! I’ll review it this week.

[saku3]

I've left a few comments.
Everything else looks good to me.
Could you please take a look when you have a chance?
Thanks for the solid work on this!

[saku3]

It looks like we can avoid using clone().

Suggested change

	.or_else(|| spec.process().clone().and_then(|p| p.no_new_privileges()))
	.or_else(|| spec.process().as_ref().and_then(|p| p.no_new_privileges()))

[saku3]

This means we want to resume the paused container at the end, right?

This might be prone to flakiness.
Would you consider using scopeguard::defer!?

[tommady]

scopeguard was removed earlier (see commit below), and in this case it would also resume the container too late since it only runs at scope exit. I’ll use an mpsc channel instead to explicitly synchronize the resume during exec --ignore-paused. Thanks for the suggestion.

123b51a

[saku3]

Shouldn’t the final value we want to set be normalized?

Suggested change

	final_cgroups_path = potential_path;
	final_cgroups_path = normalized;

[tommady]

good catcha!