Disable getty@service for containers #24743
Conversation
getty is not really useful in containers and can actually cause harm when the container is launched as privileged (i.e. it has access to the host's /dev/), as it will take over the hosts tty (and can even crash the host)
|
Hmm? Why would it have access to the host's /dev/? What container manager are you using that sets things up like that? we already carry a condition ConditionPathExists=/dev/tty0, as an indicator if the VT subsystem is around. That should suffice, as container managers generally don't make the VT subsystem available. Anyway, this PR appears wrong, it's a bug in your container manager to allow access to the host's /dev/. Generally: we want to minimize explicit checks for container environments, and instead focus on checks that check for the availability of specific subsystems. Here we do it by checking for /dev/tty0 which will exactly in the case where VT is available, and otherwise won't. or to say this differently: if you decided to patch through the VT subsystem, then we should use it. Hence closing. |
|
podman with |
|
That's a bug. They really shouldn't do that. Passing access to the VT subsystem to a container is madness. At the very least if you intend to run systemd inside of it. Sorry, but this is something we expressly don't support with systemd... |
|
We document our expectations here: https://systemd.io/CONTAINER_INTERFACE If you run a container manager that doesn't follow that, then that's out of scope for us. Sorry! |
Fair enough, I have sent this upstream instead: containers/podman#15878 |
getty is not really useful in containers and can actually cause harm when the container is launched as privileged (i.e. it has access to the host's
/dev/), as it will take over the hosts tty (and can even crash the host)