ref: Select the rootfs in the create step instead of Exec

[cmainas]

Description

Move the chooseRootfs function from reexec to the create process. In this way we can perform the preSetup function of a block based rootfs before creating any namespace. This was a block for the adoption of libcontainers, because when we use libcontainers for the monitor execution environment, we will not be able to perform such operations like the preSetup step.

This will also allow us to immediately unmount the rootfs created by containerd before creating any mount namespaces and having troubles with mount events and their propagation.

Furthermore, since chooseRootfs takes place inurunc create, we need to disable the same operation from the shim which takes place after urunc create finishes and therefore it might fail since in block-based rootfs the rootfs will get unmounted. However, this is a temporary solution and related to #816. The rootfs handling needs better control from the create task of the shim and hence we need to get deeper in the shim for a proper solution.

At last, give this opportunity, remove the tryDecode function from printing the annotations when we get them from the Spec.

Related issues

• Fixes Move the rootfs choice and preSetup step from reexec process to create process #779

How was this tested?

Running the e2e tests

LLM usage

N/A

Checklist

• I have read the contribution guide.
• The linter passes locally (make lint).
• The e2e tests of at least one tool pass locally (make test_ctr, make test_nerdctl, make test_docker, make test_crictl).
• If LLMs were used: I have read the llm policy.

[netlify]

✅ Deploy Preview for urunc canceled.

Name	Link
🔨 Latest commit	2ef715f
🔍 Latest deploy log	https://app.netlify.com/projects/urunc/deploys/6a55dd8d6331750008406025

[ananos]

thanks @cmainas! LGTM!
a few (optional) nits, just to document changes:

• Remove or clarify commented code: Replace the 9-line comment block with:

// TODO: #816 - Restore rootfs choice here once shim integration is complete.
// For now, rootfs is selected during urunc create (InitialSetup phase).

• Explain mount propagation removal: Add a comment in InitialSetup() explaining where MS_SHARED|MS_REC setup moved (probably this is handled in the shim? but please verify that!).
• explain tryDecode removal (comment/PR body/commit message) so it is documented.
• Is there a case where InitialSetup() completes but Exec() is called after state is lost? Should we add a more comprehensive error message?

[cmainas]

Hello @ananos ,

thank you for the review:

* Remove or clarify commented code: Replace the 9-line comment block with:

Yes, that comment will be helpful. I have added it.

* Explain mount propagation removal: Add a comment in `InitialSetup()` explaining where `MS_SHARED|MS_REC` setup moved (probably this is handled in the shim? but please verify that!).

In the case of block-based rootfs, this PR unmounts the host mounted rootfs and therefore there is no need to change or adjust the propagation flags of the rootfs monut, since it does not exist anymore and hence it does not get inherited from the mount namespace of the container. Unfortunately, we still had issues even altering the propagation flags, since it only affects mount events under the mount point and not for the exact mount point.

* explain `tryDecode` removal (comment/PR body/commit message) so it is documented.

This had to be replaced for long time. The annotations we set in the OCI image and the ones passed at runtime (runtime annotations) are not base64 encoded. Only the urunc.json annotations are encoded. I was just trying to verify what happens to the annotations we set in the shim and I saw log errors like "Can not decode the string spt", which was triggered from the tryDecode in the debug logs. I can remove that from this PR, if you consider it unrelated.

* Is there a case where `InitialSetup()` completes but `Exec()` is called after state is lost? Should we add a more comprehensive error message?

I am not sure I understand this question. If you mean that the state.json file somehow disappears (which is the file that a low level container runtime uses to keep track of a specific container), then there is a big problem because this file also keeps the pid, container state and other information of the container (See https://github.com/opencontainers/runtime-spec/blob/6999a89a76a0329f440d5740497bedb9dd431297/runtime.md?plain=1#L10)