mirror of
https://github.com/containers/podman.git
synced 2025-10-17 19:24:04 +08:00
Make rootless privileged containers share the same tty devices as rootfull ones
Until Podman v4.3, privileged rootfull containers would expose all the host devices to the container while rootless ones would exclude `/dev/ptmx` and `/dev/tty*`. When 5a2405ae1b3a ("Don't mount /dev/tty* inside privileged containers running systemd") landed, rootfull containers started excluding all the `/dev/tty*` devices when the container would be running in systemd mode, reducing the disparity between rootless and rootfull containers when running in this mode. However, this commit regressed some legitimate use cases: exposing non-virtual-terminal tty devices (modems, arduinos, serial consoles, ...) to the container, and the regression was addressed in f4c81b0aa5fd ("Only prevent VTs to be mounted inside privileged systemd containers"). This now calls into question why all tty devices were historically prevented from being shared to the rootless non-privileged containers. A look at the podman git history reveals that the code was introduced as part of ba430bfe5ef6 ("podman v2 remove bloat v2"), and obviously was copy-pasted from some other code I couldn't find. In any case, we can easily guess that this check was put for the same reason 5a2405ae1b3a was introduced: to prevent breaking the host environment's consoles. This also means that excluding *all* tty devices is overbearing, and should instead be limited to just virtual terminals like we do on the rootfull path. This is what this commit does, thus making the rootless codepath behave like the rootfull one when in systemd mode. This leaves `/dev/ptmx` as the main difference between the two codepath. Based on the blog post from the then-runC maintainer[1] and this Red Hat bug[2], I believe that this is intentional and a needed difference for the rootless path. Closes: #16925 Suggested-by: Fabian Holler <mail@fholler.de> Signed-off-by: Martin Roukala (né Peres) <martin.roukala@mupuf.org> [1]: https://www.cyphar.com/blog/post/20160627-rootless-containers-with-runc [2]: https://bugzilla.redhat.com/show_bug.cgi?id=501718
This commit is contained in:
@ -7,7 +7,6 @@ import (
|
||||
"os"
|
||||
"path"
|
||||
"path/filepath"
|
||||
"strings"
|
||||
"syscall"
|
||||
|
||||
"github.com/containers/podman/v4/libpod/define"
|
||||
@ -107,7 +106,18 @@ func AddPrivilegedDevices(g *generate.Generator, systemdMode bool) error {
|
||||
Source: d.Path,
|
||||
Options: []string{"slave", "nosuid", "noexec", "rw", "rbind"},
|
||||
}
|
||||
if d.Path == "/dev/ptmx" || strings.HasPrefix(d.Path, "/dev/tty") {
|
||||
|
||||
/* The following devices should not be mounted in rootless containers:
|
||||
*
|
||||
* /dev/ptmx: The host-provided /dev/ptmx should not be shared to
|
||||
* the rootless containers for security reasons, and
|
||||
* the container runtime will create it for us
|
||||
* anyway (ln -s /dev/pts/ptmx /dev/ptmx);
|
||||
* /dev/tty[0-9]+: Prevent the container from taking over the host's
|
||||
* virtual consoles, even when not in systemd mode
|
||||
* for backwards compatibility.
|
||||
*/
|
||||
if d.Path == "/dev/ptmx" || isVirtualConsoleDevice(d.Path) {
|
||||
continue
|
||||
}
|
||||
if _, found := mounts[d.Path]; found {
|
||||
@ -121,6 +131,16 @@ func AddPrivilegedDevices(g *generate.Generator, systemdMode bool) error {
|
||||
}
|
||||
} else {
|
||||
for _, d := range hostDevices {
|
||||
/* Restrict access to the virtual consoles *only* when running
|
||||
* in systemd mode to improve backwards compatibility. See
|
||||
* https://github.com/containers/podman/issues/15878.
|
||||
*
|
||||
* NOTE: May need revisiting in the future to drop the systemd
|
||||
* condition if more use cases end up breaking the virtual terminals
|
||||
* of people who specifically disable the systemd mode. It would
|
||||
* also provide a more consistent behaviour between rootless and
|
||||
* rootfull containers.
|
||||
*/
|
||||
if systemdMode && isVirtualConsoleDevice(d.Path) {
|
||||
continue
|
||||
}
|
||||
|
Reference in New Issue
Block a user