chrootarchive: Disable on MacOS and Windows

[cgwalters]

Since this is not secure, let's not pretend it is.

Prep for changing the API to be fd-relative for better support on Linux (and in theory FreeBSD).

[openshift-ci[bot]]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: cgwalters Once this PR has been reviewed and has the lgtm label, please assign mrunalp for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment Approvers can cancel approval by writing /approve cancel in a comment

[cgwalters]

It'd clearly be even better to make it not compile at all...skimming things it looks like at least some of the debug-tooling-only CLI commands would need conditional compilation, which seems fine. Just trying this as a starting point.

[mtrmac]

In principle, there are three cases:

A. In-process-only, no external dependencies, no environment assumptions. That’s pkg/archive I think (it shells out to a subprocess optionally). B. Security-critical, guarantee to be chroot-protected (chroot-or-OpenAt-protected?) C. Security-desired, use chroot if possible, but fall back to a non-isolated implementation.

Just reading the code as is, pkg/chrootarchive seems to be C. And various callers are not specifically Linux-only.

This proposes turning it into B. Apart from the pedantic API stability concerns (which… tend to be increasingly ignored in c/storage in the recent months, but I don’t know that we have made any specific decision to change the promise), what are the various nominally-cross-platform callers going to do? They can either become Linux-only (possible in principle, but a bit of an annoyance both for macOS-using developers and for general code reuse), or they have to explicitly move to A, losing some security.

I don’t know, maybe hardening the Linux version is valuable enough that we would prefer to pay the cost of moving non-Linux to A.

But, ideally, could we have both? A “best effort” mode for non-Linux and a strict implementation on Linux? … or maybe we can just keep C everywhere.

FWIW there’s also a recent release in https://github.com/cyphar/filepath-securejoin/releases/tag/v0.3.0 , vaguely in the same problem space.

[cgwalters]

what are the various nominally-cross-platform callers going to do? They can either become Linux-only (possible in principle, but a bit of an annoyance both for macOS-using developers and for general code reuse), or they have to explicitly move to A, losing some security.

My impression is that there's quite a bit of usage of moby/moby, not c/{image/storage} in the ecosystem, so we can in theory go deeper here into Linux and leave the xplatform stuff to them (apart from what podman remote needs).

I'd make the point that in practice on MacOS, we weren't using chroot today so there's no security loss.

FWIW there’s also a recent release in https://github.com/cyphar/filepath-securejoin/releases/tag/v0.3.0 , vaguely in the same problem space.

Looks nice! Definitely related. Maybe we can start using it instead of the custom code in pkg/chunked/*_linux.go.

---

Anyways...ok. I think I can make the Linux-only fd passing viable without breaking other platforms.