linux: new mount option "idmap" #780
Conversation
giuseppe
force-pushed
the
idmapped-mounts
branch
2 times, most recently
from
1494375
to
cc04828
Compare
giuseppe
force-pushed
the
idmapped-mounts
branch
2 times, most recently
from
e5452b4
to
1f284e6
Compare
Signed-off-by: Giuseppe Scrivano <[email protected]>
Signed-off-by: Giuseppe Scrivano <[email protected]>
generalize the mechanism of opening mount targets earlier. This will be necessary later to allow creating idmapped mounts before entering the user namespace. Signed-off-by: Giuseppe Scrivano <[email protected]>
prevent leaks on errors since it is called when the container is freed. Signed-off-by: Giuseppe Scrivano <[email protected]>
preparation patch to enable the creation of mounts before joining or creating a user namespace. This is needed for creating idmapped mounts that are usable from the container user namespace. Signed-off-by: Giuseppe Scrivano <[email protected]>
giuseppe
force-pushed
the
idmapped-mounts
branch
2 times, most recently
from
39e8611
to
bb5ec37
Compare
giuseppe
force-pushed
the
idmapped-mounts
branch
2 times, most recently
from
342882e
to
d3803e0
Compare
giuseppe
force-pushed
the
idmapped-mounts
branch
from
d3803e0
to
7237f85
Compare
|
LGTM |
when the "idmap" mount option is specified, create the mount outside of the container user namespace context and pass the mount fd to the container init process. Signed-off-by: Giuseppe Scrivano <[email protected]>
giuseppe
force-pushed
the
idmapped-mounts
branch
from
7237f85
to
827b873
Compare
|
Just a small question so when mount is |
yes, the mounts are created outside the user namespace but after the user namespace is created. That is why we cannot do it before the fork. |
|
LGTM |
pass down the "idmap" mount option to the OCI runtime. Needs: containers/crun#780 Closes: containers#12154 [NO NEW TESTS NEEDED] there is no crun version yet that support the new feature. Test case (must run as root): podman run --rm -v foo:/foo alpine touch /foo/bar podman run --uidmap 0:1:1000 --rm -v foo:/foo:idmap alpine ls -l /foo total 0 -rw-r--r-- 1 root root 0 Nov 15 14:01 bar Signed-off-by: Giuseppe Scrivano <[email protected]>
|
Do you have plan to extend the OCI spec to support idmapped rootfs too? |
|
I've not thought about that yet. Is the use case to apply the recursive read-only flag to the entire container? How would it work with mounts that need to be writeable? |
The main usecase of idmapped Haven't thought much about recursive read-only mounts with idmapped rootfs. |
|
sorry, somehow my brain got confused with "recursive mounts". I am not sure. Is it something the OCI runtime should deal with? So far setting the rootfs is a responsibility of the container engine, but I see the value of reusing the existing code and hiding the mount from the host. One thing to think about, do we want to set the idmapped for the whole overlay mount or apply it only to the lower layers? In the latter case, then OCI runtime can't help. |
when the "idmap" mount option is specified, create the mount outside of the container user namespace context and pass the mount fd to the container init process.
Signed-off-by: Giuseppe Scrivano [email protected]