Support for copying between security domains

[cgwalters]

(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

$ rpm-ostree rebase ostree-unverified-image:containers-storage:[/home/swick/.local/share/containers/storage]localhost/my-silverblue-toolbox-image:latest

And reported

one more thing: it creates the directory ~/.local/share/containers/storage/overlay/l/ owned by root, making podman images fail to chown it.

I think in general the c/image stack would need to learn to do one of a few options here:

• Fork into two processes, where the process operating on the unprivileged store calls setuid() to the owner of that directory
• setfsuid - but this one being process global just heavily conflicts with goroutine threads and seems like a nonstarter
• Just avoid any writes to the target directory at all (no locking) and accepting the possibility of race conditions

[cgwalters]

Fork into two processes,

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 skopeo experimental-image-proxy; basically, an in-band primary channel for metadata, but instead of passing tarballs over a pipe, we pass readonly file descriptors for filesystem objects. In the case of a privileged caller copying from an unprivileged store, this would allow us to use reflinks (if available) which would be a giant speed and disk space improvement.

[cgwalters]

.oO(thinking more) - maybe we should think of this like a "composefs clone" operation really, with support for extra metadata (tar-split stuff).