Join GitHub today
Add the ability to map containers to a user host-side #22415
Before getting into the details, I want to point out that I suspect a feature like what I'm about to suggest could solve many permission related snags when using Docker.
So as to prevent this suggestion from getting mired in philosophical objections, this ticket is not advocating permanently storing credentials inside a container. I don't do that and I don't suggest anyone else do it either!
The current method of UID spoofing inside of a container via
The feature I'd like to request is to have a flag added to
If you're interested in an extended explanation, read on!
We've all heard about people having issues with temporarily binding SSH credentials and similar
One non-exclusive example is when trying to forward either an SSH socket or the SSH directory on a Linux host, because SSH insists on proper home directories, I've been unable to get secure connections working without having to make my container aware of the environment it is running in! The best I've been able to dream up is bind mounting
Another more common example would be when files are created by the container, if the bound filesystem is ext or otherwise linux-compatible, the UID of files is set to root (or whoever I run my container as). On Linux, in order to not blast my filesystem with files having UID/GID 0, I have to tell my containers to run their processes as my current user via
So, I currently am stuck avoiding the complexity by staying as root. Everything works because all containers have a root user fully configured. But now without any better option, all Docker containers that want to avoid being polluted with hacks are forced to write files as UID 0!
As I mentioned above, switch over to Windows or OSX and this problem goes away because they don't share the same users as the container and the filesystems aren't compatible. Instead, vboxsf, samba and other drivers are actually emulating the feature I'm requesting here!
So, this clearly identifies the fact that while it's nice to control who the container runs its process as, it would actually be more desirable to optionally map the uid (and gid?) flag for any changes to the filesystem from the container, host-side. All the while, still allowing the container to function as whoever it needs to be internally.
We need a way to bind users as well.
Nope, and I was even thinking about this issue today. IIRC, @thaJeztah agreed with the value behind such a feature, might have been advocating for it internally (correct me if I'm wrong
This is probably one of the more glaring oversights in the docker platform and in a strange twist, keeps me preferring to work with it on macOS/Windows instead of natively on linux!
Feel free to retweet, this issue is as old as my daughter!
If the main issue is to have the ability to bind-mount files from your host into a container, then this is largely the same issue as;
And comes down to the ability to remap user-ids inside the container. This might be possible with a kernel that supports shiftfs or a FUSE filesystem.
It's not something that should be (or could be) enabled by default, as;
For Docker Desktop (Docker for Mac / Docker for Windows), the "ignore ownership" feature was implemented because Docker Desktop is targeted at developer use-cases, not for production (in production situations, giving a container access to files on the host is especially not desirable)
I'm not sure I understand the distinction ~"people dev on Windows/macOS" as I'm sure plenty of people develop on linux as well. If that's really an explanation for the difference in behaviour, they surely need some equivalent that is easy to use.
The mappings should be configured per volume. So if I bind a volume to a container, I should be able to set a uid and/or gid that all write operations to that volume map out to on the host. Internally the container will retain its own behaviour, but I can't have containers that write to uids and gids that might not even be configured on my host system.
There is clearly a missing abstraction here.
@cpuguy83 - Sorry, can you elaborate? I might not be following on that one, why would FUSE be necessary?
Really, what this ticket represents applies regardless of what the current state of things is. I don't think it's at all a stretch to say that my
As a practical but still contrived example: If I'm running on a system and one container writes as
To me, it seems like the only possible answer here is that we need some way during instantiation to abstract the filesystem operations that originate from within the container to the local system. More importantly, this has to be possible without having to put that information in the containers themselves.
Ideally: Each container is responsible for its own security abstractions and when configured, have all operations performed on bound filesystems mapped to a specific uid/gid as defined by the host.
Could we have an an option to use FUSE on Linux then? This issue causes huge amounts of problems for devs who use linux in our organisation and maintaining workarounds to let them do their jobs is irritating.
I've been experimenting specifically with a filesystem for mapping UID/GID's mapped for user namespaces... #38795
How something like this might work for mapping a name in the container to a name on the host... I'd leave that to people who are interested in this.