-
Notifications
You must be signed in to change notification settings - Fork 315
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
linux: new mount option "idmap" #780
Conversation
1494375
to
cc04828
Compare
e5452b4
to
1f284e6
Compare
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
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 <gscrivan@redhat.com>
prevent leaks on errors since it is called when the container is freed. Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
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 <gscrivan@redhat.com>
39e8611
to
bb5ec37
Compare
342882e
to
d3803e0
Compare
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 <gscrivan@redhat.com>
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 <gscrivan@redhat.com>
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 gscrivan@redhat.com