[q3k]

I would absolutely say it's a production antipattern to run a container with access to some already existing host files belonging to some other user.

However, this is something that's basically unavoidable if you're attempting to use OCI/Docker for dev where you access a developer's source code checkout from a container running a standardized language runtime. And that's what a lot of people use OCI/Docker for...

[dividedbyzero]

Couldn't you run into this issue when mounting device files? I believe doing that for accessing external hardware or sensors is not all that uncommon.

[q3k]

Sure, that's one of the cases when this might needed in prod (although in the parent post I meant only access to honest-to-god data files, not things like bindmounting /dev).

In practice bindmount smell can also be somewhat alleviated by using things like k8s device plugins to request things at a higher level ('I want GPU access' vs. 'please bindmount /dev/drm... and use the proper modes'). It's still effectively a bindmount, but some extra security precautions can be made to ensure exclusive access and that no arbitrary mounts from the host are permitted. And things like k8s device plugins can also poke at file modes and other namespace magic at runtime so that the end user never has to worry about things like UID/GID and chardev modes. That IMO prevents the smell associated with random host bindmouts.

[dividedbyzero]

I wasn't aware of k8s device plugins, that seems like it would help with that, if k8s is an option. Thanks for the pointer!

[q3k]

You're welcome :).

They're also very easy to write, so if you ever happen to run k8s and need to give workloads access to some odd/custom host hardware, implementing a proper plugin for it is quite painless and gives much better guarantees than plain bindmounts.