Why can root user (in guest) write to my mounted directory?

[loneboat]

I have the following in my container's config file:

unprivileged: 1

lxc.mount.entry: /tank/git_repositories mnt/git_repositories none bind 0 0

#             GUEST    HOST    NUM
lxc.idmap: u      0  100000   1000
lxc.idmap: u   1000  200101      1
lxc.idmap: u   1001  101001  64535

lxc.idmap: g      0  100000   1000
lxc.idmap: g   1000  200101      1
lxc.idmap: g   1001  101001  64535

And the following is a directory listing from my host:

root@proxmox:# ls -al /tank/
drwxr-xr-x  5 root   root    5 Dec 24 11:02 .
drwxr-xr-x 23 root   root   23 Dec 19 17:51 ..
drwxr-x---  4 200101 200101  5 Jan 17 08:45 git_repositories

So the user 1000 on my guest is mapped to the user 200101 on my host. This seems to work as expected - if I go into the guest as user 1000 and write a file to /mnt/git_repositories/test_file, that file is created and owned by user 200101 on the host. Nice!

But I also noticed that if I log into the guest as the guest's ROOT user (0), I am ALSO able to create files under /mnt/git_repositories (on the guest). Those files then show up on the host, created/owned by user 100000.

I don't understand how this works - I thought any interaction in the guest under user 0 would be mapped to activity of user 100000 on the host - yet the uid 100000 does not have any privileges on the host (in fact, that user id does not even EXIST on the host!). So how was user 100000 permitted to write files to that directory on my host? The directory on the host has permissions rwxr-x---, so only the owner (uid 200101) should be able to write to it.

Am I misunderstanding something? Or do I have something misconfigured? Thanks for any help!

 

[wbumiller]

But I also noticed that if I log into the guest as the guest's ROOT user (0), I am ALSO able to create files under /mnt/git_repositories (on the guest). Those files then show up on the host, created/owned by user 100000.

When you're in the container as root, you are using a user which has the `CAP_DAC_OVERRIDE` capability ("bypass file permission checks", see man 7 capabilities[1]) within its namespace. The directory `git_repositories` is owned by a user for which there exists a valid mapping inside the container's user namespace, therefore this capability applies and root is considered privileged over that user and their files.
If the "real" user 200101 did not have a valid user id mapping in the container's namespace on the other hand, the capability would not apply and the kernel would move up into the host namespace and see user 100000 with no capabilities trying to access a file of another unrelated user 200101.

user id does not even EXIST on the host!

Mappings of "users" (as in names) to IDs via /etc/passwd & friends is of no concern to the kernel.
What matters here is that there exists a mapping for that user in the current namespace, so capabilities as seen from within the namespace apply.

[1] http://man7.org/linux/man-pages/man7/capabilities.7.html

 

[loneboat]

When you're in the container as root, you are using a user which has the `CAP_DAC_OVERRIDE` capability ("bypass file permission checks", see man 7 capabilities) within its namespace. The directory `git_repositories` is owned by a user for which there exists a valid mapping inside the container's user namespace, therefore this capability applies and root is considered privileged over that user and their files.
If the "real" user 200101 did not have a valid user id mapping in the container's namespace on the other hand, the capability would not apply and the kernel would move up into the host namespace and see user 100000 with no capabilities trying to access a file of another unrelated user 200101.


Mappings of "users" (as in names) to IDs via /etc/passwd & friends is of no concern to the kernel.
What matters here is that there exists a mapping for that user in the current namespace, so capabilities as seen from within the namespace apply.

Excellent explanation. Thank you so much!