What is the plan with binary dependencies to tar (and nsenter)?

[apostasie]

Description

I was wondering why we shell out to the tar binary instead of using golang archive/tar.

Looking at our code, I assume it is because of rootless/nsenter. Is this correct? Are there other reasons?

On the question of nsenter. This comment here:
https://github.com/containerd/nerdctl/blob/main/pkg/rootlessutil/parent_linux.go#L92
suggests removing the dependency on the nsenter binary. The comment does not say if it is only in the context of parent.go, or generally in our codebase.

From what I know, there does not seem to be a pure golang replacement for nsenter (kube does shell out as well right?).
runc has a CGO one though, but I am pretty sure we do not want to drag in CGO in here.

So, questions are:
a. do we want to replace the dependency on binary nsenter? if so, is there a plan / pointers for that?
b. do we want to replace the dependency on the tar binary? ditto

Thanks in advance :).

Steps to reproduce the issue

No response

Describe the results you received and expected

na

What version of nerdctl are you using?

na

Are you using a variant of nerdctl? (e.g., Rancher Desktop)

None

Host information

No response

[AkihiroSuda]

Just using tar command on the host would be simpler

Originally posted by @AkihiroSuda in #643 (comment)

[AkihiroSuda]

We may try to remove those dependencies (probably by re-executing /proc/self/exe with proc attrs to enter namespaces), but we may not gain so so huge benefits

[apostasie]

We may try to remove those dependencies (probably by re-executing /proc/self/exe with proc attrs to enter namespaces), but we may not gain so so huge benefits

Is using the tar binary the only thing preventing nerdctl cp from working on Windows, or is there more?

[AkihiroSuda]

We may try to remove those dependencies (probably by re-executing /proc/self/exe with proc attrs to enter namespaces), but we may not gain so so huge benefits

Is using the tar binary the only thing preventing nerdctl cp from working on Windows, or is there more?

Not familiar with Windows.
The windows implementation is likely to diverge from the Linux implementation, assuming that Windows still lacks the equivalent of /proc/PID/root.

[apostasie]

Ok. Thanks for the infos.
Currently looking into cp, so, will take that into account.