Support for copying between security domains #1849
Comments
Tangentially related to this, I think a mechanism that would make sense for copying here would be quite similar conceptually to what landed in the |
|
.oO(thinking more) - maybe we should think of this like a "composefs clone" operation really, with support for extra metadata (tar-split stuff). |
The status quo today is basically that with a "pure ostree" container image, one can pull it, and one *can* re-export it with `ostree container encapsulate`...but doing so loses *all chunking* i.e. you end up with a single giant layer again. Further, we don't support exporting derived images at all. Fix both of these with a new CLI and API, for example: ``` $ ostree container image export --repo=/path/to/repo registry:quay.io/exampleos/someos:latest containers-storage:localhost/exampleos ``` Now...before one gets too excited, this is still suboptimal in a bunch of ways: - Copying to `containers-storage` is super inefficient, we indirect through a local `oci` directory because of the lack of "push" support in containers-image-proxy, *and* we end up with a full physical copy of the files even when we *could* reflink; cc containers/storage#1849 - Because we don't currently save tar-split data, the use case of pushing to a registry is virtually guaranteed to produce changed diffids, and we'll hence end up duplicating layers on the registry Now what is more interesting is that this code is going to help us a bit for the use case of "recommitting" a derived container image. Signed-off-by: Colin Walters <walters@verbum.org>
|
cc ostreedev/ostree-rs-ext#642 which definitely wants a better interface to c/storage than passing tarballs around. And really the more I think about things like this, the more strongly I feel that composefs is the right core to things. For example, when copying a container image from rootful podman to rootless (or vice versa), because fsverity is implemented in the kernel (a common shared trust domain) and enforces read-only state for content we can efficiently provide a file descriptor opened from a user's home directory and reflink (or copy if we have to) into the rootful container storage, while knowing that:
|
The status quo today is basically that with a "pure ostree" container image, one can pull it, and one *can* re-export it with `ostree container encapsulate`...but doing so loses *all chunking* i.e. you end up with a single giant layer again. Further, we don't support exporting derived images at all. Fix both of these with a new CLI and API, for example: ``` $ ostree container image reexport --repo=/path/to/repo registry:quay.io/exampleos/someos:latest containers-storage:localhost/exampleos ``` Now...before one gets too excited, this is still suboptimal in a bunch of ways: - Copying to `containers-storage` is super inefficient, we indirect through a local `oci` directory because of the lack of "push" support in containers-image-proxy, *and* we end up with a full physical copy of the files even when we *could* reflink; cc containers/storage#1849 - Because we don't currently save tar-split data, the use case of pushing to a registry is virtually guaranteed to produce changed diffids, and we'll hence end up duplicating layers on the registry Now what is more interesting is that this code is going to help us a bit for the use case of "recommitting" a derived container image. Signed-off-by: Colin Walters <walters@verbum.org>
The status quo today is basically that with a "pure ostree" container image, one can pull it, and one *can* re-export it with `ostree container encapsulate`...but doing so loses *all chunking* i.e. you end up with a single giant layer again. Further, we don't support exporting derived images at all. Fix both of these with a new CLI and API, for example: ``` $ ostree container image reexport --repo=/path/to/repo registry:quay.io/exampleos/someos:latest containers-storage:localhost/exampleos ``` Now...before one gets too excited, this is still suboptimal in a bunch of ways: - Copying to `containers-storage` is super inefficient, we indirect through a local `oci` directory because of the lack of "push" support in containers-image-proxy, *and* we end up with a full physical copy of the files even when we *could* reflink; cc containers/storage#1849 - Because we don't currently save tar-split data, the use case of pushing to a registry is virtually guaranteed to produce changed diffids, and we'll hence end up duplicating layers on the registry Now what is more interesting is that this code is going to help us a bit for the use case of "recommitting" a derived container image. Signed-off-by: Colin Walters <walters@verbum.org>
(Sorry if this is a duplicate, I tried to search here and didn't find it...tried to search in podman issues but there are soooo many issues and these are generic search terms. Maybe someday github will have an LLM integrated for search instead)
An rpm-ostree user wanted to copy an image built in their rootless podman storage to the host root storage, doing
And reported
I think in general the c/image stack would need to learn to do one of a few options here:
setfsuid- but this one being process global just heavily conflicts with goroutine threads and seems like a nonstarterThe text was updated successfully, but these errors were encountered: