In my opinion, if an application requires more access than a docker container gives by default, then that application should probably just run in a VM. If the application needs more access because it needs to manage or control some hardware, then it should be tailored to the O/S and have a small core service that runs naked under systemd or whatever. If fancy management of that core service is needed, it can expose a port that an application can talk to, that's safely isolated in a docker container.
Maybe that's just daydreaming about a perfect world, but I agree that it should be easy to reason about the access levels.
What about an application like vim? It should be able to access any file I pass that is explicitly opened, but not much more. That is hard to express with current tooling.
You shouldn't run an application like vim in Docker. Unless your server is running Vim as some sort of service, in which case it should only open files in a volume you bound to it.
Vim is exactly the kind of application you would run in a virtual machine.
You could do it with a file picker API that opened an out-of-process file picker. I'm pretty sure this is how WinRT works. Would be tricky for a purely command line workflow, but very doable with a GUI.
Even file picker APIs are severely lacking with regards to any multi-file filetypes, where opening one file means having to subsequently access further additional files, too (but which files exactly cannot necessarily defined in advance because it depends on the contents of the initially opened file).
Maybe that's just daydreaming about a perfect world, but I agree that it should be easy to reason about the access levels.