Support subpath paths for -v or --mount

[larsks]

Feature request description

I'm glad that support for subpath mounts in pod manifests was added in #16803. I'd like to see the same capability exposed via podman run, either by extending the syntax of --volume, so that we can write:

podman run -v somevolume/internal/path:/container/path ...

Or by adding an additional subpath keyword to --mount, so that we can write:

podman run --mount type=volume,subpath=internal/path,destination=/container/path

Suggest potential solution

I think the reasons for wanting to do this are covered in #12929. I just want to be able to do it from the command line because in many situations a simple podman run ... invocation is both faster and more effective than setting up a pod manifest.

I think adding the subpath keyword to --mount would be the cleanest and least disruptive way of implementing this feature.

Have you considered any alternatives?

While it's possible to do this using a pod manifest, the behavior of podman kube play is different from the behavior of podman run; in particular, it's not really designed for running a container interactively from the command line.

Additional context

Add any other context or screenshots about the feature request here.

[rhatdan]

The trend is to require the use of --mount rather then --volume, for ultimate flexibility and this seems reasonable.
WDYT @vrothberg @mheon ?

[mheon]

I recall someone had security concerns with this when it was originally proposed - maybe Giuseppe?

…

On Sun, Nov 12, 2023 at 08:23 Daniel J Walsh ***@***.***> wrote: The trend is to require the use of --mount rather then --volume, for ultimate flexibility and this seems reasonable. WDYT @vrothberg <https://github.com/vrothberg> @mheon <https://github.com/mheon> ? — Reply to this email directly, view it on GitHub <#20661 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3AOCGSNPOJFXVWTS6WOHDYEDEUNAVCNFSM6AAAAAA7HVODDCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBXGEZDONJWGE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[giuseppe]

yes, it was not implemented safely originally. If we open the mount first as we already do for the kube path, then it is safe as another container cannot create a malicious symlink to escape it.

[larsks]

It looks like Docker has just added this feature in v26.0.0; there is now a volume-subpath mount option:

docker run -it --rm \
  --mount type=volume,source=vol-web,target=/data,volume-subpath=pgdata \
  alpine sh

[cyqsimon]

Ran head first into this today.

My compose.yml declares several containers that share a volume but are supposed to be mounted on distinct subpaths. But I was surprised to see that when I brought up the containers using podman compose (delegates to docker-compose), the subpath key is SILENTLY ignored and all files went into the volume root, which is BAD. I was lucky not to have run into any file conflicts.

I think this is another important concern to address, because if it's implemented without special attention to and handling of backward compatibility, the effective file layout within the volume will become inconsistent with actual data. As a consequence of this, at best, users of compose files may find their data "gone" after an update (because it now mounts an empty subpath); and at worst, the container may overwrite existing files at incorrect locations, causing a data corruption.

Please correct me if I'm wrong (and I really hope I'm wrong), but I don't think there is a way to retroactively sort existing data (which is often a mixed blend of data from multiple containers) into subpaths cleanly. So I suppose this would have to be a breaking change with the appropriate warnings put in place.

[gilesknap]

I have the same issue as @cyqsimon. I'm building a framework that I want podman and docker users to be able to make use of.

My compose files work beautifully in both except that subpath is silently ignored when using podman.

I don't have a good workaround to this. I'll probably have to create multiple volumes and then somehow track them all in the consumer.

[gilesknap]

Re the breaking change point. For me there are file name clashes so I'm already broken in podman.

If that were not the case then I may never have noticed the discrepancy and would be prone to data loss if podman is updated to support sub path.

Therefore I suggest a config option to enable the feature, defaulting to 'legacy', i.e. ignore sub-path in compose.yml.