WithBindMount is broken on Fedora, RHEL and derivatives.

[tmds]

WithBindMount doesn't work on SELinux systems because the src directories don't have the right labels.

For example:

$ podman run --rm --mount type=bind,src=$(mktemp -d),target=/mnt docker.io/library/busybox:latest ls /mnt
ls: can't open '/mnt': Permission denied

The relabel option needs to be added with either a private or shared value. See podman --mount.

For example:

$ podman run --rm --mount type=bind,src=$(mktemp -d),target=/mnt,relabel=shared docker.io/library/busybox:latest ls /mnt
/tmp/AspireExample/AspireExample.AppHost
$ podman run --rm --mount type=bind,src=$(mktemp -d),target=/mnt,relabel=private docker.io/library/busybox:latest ls /mnt

The difference between private and shared is whether multiple containers can share the volume.

Rather than expose this to the user, because the Aspire orchestrator is meant for development it could unconditionally add ,relabel=shared.

From the Docker documentation, it seems that the --mount argument doesn't support relabeling. It can be done by using -v instead of --mount and adding :z for shared (or :Z for _private).

Afaik on systems that don't support SELinux, passing this setting does not cause an error and it is ignored.

[tmds]

The fix for this is to add the flag for relabling as described in the first comment. Can this be included in one of the Aspire preview releases?

Note: SELinux is a kernel security feature, it is not podman specific.

[tmds]

Fixing this requires small changes to the volume arguments the orchestrator uses when launching a container through docker/podman.

cc @karolz-ms

[tmds]

Can someone take a look at this?

[danegsta]

One concern with adding support for SELinux relabeling in Aspire is the potential security implications of the AppHost making changes to security settings on the host machine when it runs. My understanding is that there are potential concerns with incorrectly labeling a system folder using the :Z argument such that it might render a system virtually unusable until the labels could be manually edited from a safe mode boot (I'm basing this on Docker's explanation of why they chose not to support SELinux labels in the new mount syntax, so if that's off base, let me know).

This feature would need to be reviewed by our security folks before we could properly schedule it. My understanding is that there are manual steps a user can do to apply SELinux labels for a given folder (ranging from manual relabeling to running a temporary container binding to a particular volume with :z)? That's probably going to need to serve as a workaround for the near term.

[danegsta]

Sounds like the minimum requirement for supporting this would be interactive confirmation from users before applying any SELinux labels; that would likely require us to detect if SELinux is enabled/enforced for a particular system as well as, ideally, whether appropriate labels are already configured to grant access (such that prompting wouldn't be necessary).

@tmds is there any standard way to check for either of those conditions?

[tmds]

My understanding is that there are potential concerns with incorrectly labeling a system folder using the :Z argument such that it might render a system virtually unusable until the labels could be manually edited from a safe mode boot (I'm basing this on Docker's explanation of why they chose not to support SELinux labels in the new mount syntax, so if that's off base, let me know).

I think the issue may be specific to Docker. The Docker daemon runs as root which means it has permissions to relabel the system folders, which then may cripple the system. A rootless podman instance won't have these permissions.

Perhaps the SELinux relabling options could be included when podman is used, but not for docker?

SELinux enabled systems (Fedora, Red Hat, SUSE Linux Enterprise, ...) use podman as their default container tool, so that will make things "just work" on these distros.

@danegsta wdyt?