Skip to content

Commit eb676de

Browse files
cypharkolyshkin
authored andcommitted
memfd-bind: elaborate kernel requirements for overlayfs protection
Arguably these docs should live elsewhere (especially if we plan to remove memfd-bind in the future), but for now this is the only place that fully explains this issue. Suggested-by: Rodrigo Campos <[email protected]> Signed-off-by: Aleksa Sarai <[email protected]> (cherry picked from commit ac43589) Signed-off-by: lfbzhm <[email protected]>
1 parent 82f3af8 commit eb676de

File tree

1 file changed

+7
-7
lines changed

1 file changed

+7
-7
lines changed

contrib/cmd/memfd-bind/README.md

+7-7
Original file line numberDiff line numberDiff line change
@@ -1,13 +1,13 @@
11
## memfd-bind ##
22

33
> **NOTE**: Since runc 1.2.0, runc will now use a private overlayfs mount to
4-
> protect the runc binary. This protection is far more light-weight than
5-
> memfd-bind, and for most users this should obviate the need for `memfd-bind`
6-
> entirely. Rootless containers will still make a memfd copy (unless you are
7-
> using `runc` itself inside a user namespace -- a-la
8-
> [`rootlesskit`][rootlesskit]), but `memfd-bind` is not particularly useful
9-
> for rootless container users anyway (see [Caveats](#Caveats) for more
10-
> details).
4+
> protect the runc binary (if you are on Linux 5.1 or later). This protection
5+
> is far more light-weight than memfd-bind, and for most users this should
6+
> obviate the need for `memfd-bind` entirely. Rootless containers will still
7+
> make a memfd copy (unless you are using `runc` itself inside a user namespace
8+
> -- a-la [`rootlesskit`][rootlesskit] -- and are on Linux 5.11 or later), but
9+
> `memfd-bind` is not particularly useful for rootless container users anyway
10+
> (see [Caveats](#Caveats) for more details).
1111
1212
`runc` sometimes has to make a binary copy of itself when constructing a
1313
container process in order to defend against certain container runtime attacks

0 commit comments

Comments
 (0)