Ich lerne die Containertechnologien von Linux kennen und habe selbst eine minimale Containerimplementierung geschrieben. Ich bin derzeit verwirrt über Konsolen/Terminals für Containerprozesse, da ich das steuernde Terminal im Container „wiederverwende“ /dev/console(anstatt ).c 5 1
Ich bestimme das aktuelle Terminal von /proc/self/fd/0und /proc/self/fd/2, lese seinen Geräteknoten (Haupt- und Nebenknoten) und mknod(2)verwende die erkannten Geräteknoten, um /dev/consoleeinen Knoten im Container zu erstellen.
Dies scheint problemlos zu funktionieren, wenn eine reguläre Anwendung wie /bin/shPID 1 (im PID-Namespace) ausgeführt wird, jedoch nicht, wenn sie über ein Init-System ausgeführt wird (ich habe hierfür BusyBox verwendet).
Hier ist mein /etc/inittabRoot-Dateisystem für BusyBox:
::sysinit:/bin/true
::respawn:-/bin/sh
Die von init gestartete Shell beschwert sich jedoch immer can't access tty; job control turned off. Ich habe auch versucht, denselben Host-TTY-Knoten für /dev/tty(anstelle von c 5 0) zu verwenden, aber dieses Problem besteht weiterhin.
Ich habe mir den Quellcode von angesehen systemd-nspawnund festgestellt, dass eserstellt ein "weitergeleitetes PTY", wo der Container auf einem neuen PTY läuft, das an die Hostseite „weitergeleitet“ wird. Der Code ist für mein Bildungsprojekt zu komplex und daher für mich nicht umsetzbar.
Wie kann ich das Host-Terminal für den Container verwenden?
Details: Mein Containerprogramm hat clone(2)nur ein Kind mit Flags = CLONE_NEWGROUP | CLONE_NEWNET | CLONE_NEWPID | CLONE_NEWIPC | CLONE_NEWUTS | SIGCHLD, und das Kind richtet Fähigkeiten (Blacklisting) und Seccomp (Whitelisting, Syscall-Liste übernommen ausDocker), bevor es pivot_root(2)in das Container-Rootfs und execve(2)in die Zielanwendung kopiert wird.
Ich experimentiere derzeit mit Linux 5.3 (Ubuntu 18.04 HWE), erwarte aber nicht, dass dies bei neueren Linux-Versionen anders sein wird.