Since the rootless mode reached general availability, I am trying it out.
I have a problem, though.
When I mount my working directory with docker-compose, the UID mapper works fine.
Every file created with UID 0 (root) inside the container got mapped to my user on the host system.
However, when I create a file with a user other than root inside the container, the file owner will be set to a UID without a user on the host system. And now we are back to square one, with the same permission related issues.
Can I map more UIDs apart from 0 to my user on the host system?
If not, how do you deal with the mounted file permission during the application development?
In summary, rootless mode is more about security than usability. They would rather map user to nobody than an actual user.
If that is the case, it is not for me. I would rather look into userns-remap in normal mode for my development machine than rootless mode. And I donāt have much issue with my production machines in the first place.
Group permission does work in some of my use cases, but not all.
If somebody reading this topic in the future, feel free to add more info. Maybe rootless mode got better then. I will still monitor the reply, and would love to hear the news.
Is the conclusion that userns-remap does not work with rootless docker?
I tried using rootless docker with both a domain user, and a local user, on Ubuntu 20.04 but only got errors. /etc/subuid and /etc/subgid have the username:startid:idrange entries
Example commands and errors:
$ dockerd-rootless.sh --userns-remap=ljason:ljason
...
INFO[2021-01-22T17:06:09.607299361-08:00] Starting up
WARN[2021-01-22T17:06:09.607732164-08:00] Running in rootless mode. This mode has feature limitations.
INFO[2021-01-22T17:06:09.607939765-08:00] Running with RootlessKit integration
INFO[2021-01-22T17:06:09.608571470-08:00] User namespaces: ID ranges will be mapped to subuid/subgid ranges of: ljason
Cannot create daemon root: /home/ljason/.local/share/docker/305536.305536: chown /home/ljason/.local/share/docker/305536.305536: invalid argument
[rootlesskit:child ] error: command [/home/ljason/bin/dockerd-rootless.sh --userns-remap=ljason:ljason] exited: exit status 1
[rootlesskit:parent] error: child exited: exit status 1
and after modifying docker-rootless.sh to get ājason:domain userā past the argument quotingā¦
$ dockerd-rootless.sh
...
exec dockerd --userns-remap=jason:domain users
INFO[2021-01-22T17:17:55.673903034-08:00] Starting up
WARN[2021-01-22T17:17:55.674328737-08:00] Running in rootless mode. This mode has feature limitations.
INFO[2021-01-22T17:17:55.674496638-08:00] Running with RootlessKit integration
INFO[2021-01-22T17:17:55.688611729-08:00] User namespaces: ID ranges will be mapped to subuid/subgid ranges of: jason
Cannot create daemon root: /home/jason/.local/share/docker/170000.170000: chown /home/jason/.local/share/docker/170000.170000: invalid argument
[rootlesskit:child ] error: command [/home/jason/bin/dockerd-rootless.sh] exited: exit status 1
[rootlesskit:parent] error: child exited: exit status 1
Iāve been trying to grapple with the concept as well for a week now. I couldnāt find a way to gain full rights as the host user of the files you create in your (non-sudo) container, except the ones the container root creates.
Everything else is mapped to <100000>+(container UID)-1 and is not fully modifiable by the host user.
At this point, I donāt see the point of this āfeatureā. What were we supposed to be getting with this remapping?
I read here and there that full file access could be possible by editing the ACL settings of the mounted volumes, but Iām not ready to open this can of worms yet.
This is mainly for security reason not for accessing files more easily. Using rootless mode your docker daemon will not run as root, so it will not have permission to read files that only root users should be able to access. Being able to access some files more easily from the host is just a side-effect I guess, when you run everything in the container as root, because that root will be your user on the host. When an other user creates something in the container, you still need to set the proper user groups or read, write execution privileges on the created file or folder.
So, the remapping range was basically meant to be a convenience for the case where you āexposeā files created by the container to the host system. But you donāt want to create those files with the container UIDs, because they might step on the host system UIDs and wreck chaos.
The fact that we are getting a direct mapping between rootless mode host user and container root is a happy accident.
This makes things a bit more clear. It seems I was expecting some other purpose and features that were never meant to be.