--security-opt="label=disable" not supported in finch run

[stmcginnis]

Describe the bug

The --security-opt argument to finch run is used to set security options.

When using docker, we a project that disables security labeling using --security-opt label=disable. According to the Docker documentation, this is used to "Turn off label confinement for the container".

It appears none of the label=* values there are valid with Finch. They result in:

WARN[0000] Unknown security-opt: "label" 

Steps to reproduce

Run a command, passing one of the label security configuration options.

Expected behavior

Security labeling should be modified.

[mharwani]

Hi @stmcginnis, nerdctl, our CLI tool, currently does not support SELinux context labeling (--security-opt label) like docker. There is an open issue upstream regarding this: containerd/nerdctl#11.

I'm curious to understand the use case for this considering Mac does not use SELinux labels for its filesystem.

[stmcginnis]

Hey @mharwani - thanks for the pointers.

It is a bit weird, I'll admit. I think ideally it would just be ignored on macOS. The reason for even bringing this up is in Bottlerocket I was looking at what it would take to build the project on macOS. In the Bottlerocket build script we run an SDK container to perform a lot of the build steps.

https://github.com/bottlerocket-os/bottlerocket/blob/develop/Makefile.toml#L444

That flag is needed on Linux, but obviously then not needed on macOS. If it were just ignored as not applicable, that would be the simplest. If there needs to be a bunch of conditional logic to determine what platform we are running on, then that gets very messy very quick.

My 2 cents at least. ;)

[mharwani]

Thanks for the context @stmcginnis, that makes sense.

I think regardless of whether this is resolved in nerdctl, it's a good idea to ignore the --security-opt options completely in Finch. I don't think users should be able to control the Linux security features of containers running inside a VM, but maintaining compatibility with the Linux CLI is important for use cases like yours.