[Lookbehind]

Ich hab ein interessantes Phänomen. Wenn ich mit netstat versuche die PID zu einem Port zu finden, bekomme ich folgendes:

# netstat -tlpn 
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      -                   
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      169/sshd: /usr/sbin 
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      -                   
tcp6       0      0 :::111                  :::*                    LISTEN      -                   
tcp6       0      0 :::80                   :::*                    LISTEN      197/apache2         
tcp6       0      0 :::4949                 :::*                    LISTEN      168/perl            
tcp6       0      0 ::1:25                  :::*                    LISTEN      -                   
tcp6       0      0 :::443                  :::*                    LISTEN      197/apache2         
tcp6       0      0 :::25565                :::*                    LISTEN      -

Ja, ich lasse das ganze als root laufen. Allerdings in einem (Unprivileged-)Container, der so ziemliche aller Capabilities beraubt wurde, die er nicht unbedingt braucht. Das es hier also zu Problemen kommen kann, ist nicht SO überraschend.

Was ich hier allerdings total faszinierend finde: Für einige Ports kennt netstat die PID, für andere nicht. Würde er die PID für keinen Prozess kennen, würde mich das nicht überraschen. Aber dieses Phänomen kann ich nicht so ganz erklären.

Ja, prinzipiell hat die richtige Antwort nur vier Buchstaben: "RTFM"
Allerdings verläuft man sich da recht schnell, wenn man von dieser Seite der Gleichung kommt. ... Ok, ICH verlaufe mich da schnell.

Das ganze ist kein wirkliches "Problem" aber interessieren würde es mich schon. Hat zufällig jemand einen heißen Tipp in welcher Richtung ich da weiter suchen muss um fündig zu werden?

[foobar]

Naja, grundsätzlich muss nicht jeder offene Port auch mit einem Prozess verbunden sein. Ein Klassiker sind Ports, die keinem Prozess, sondern dem Kernel gehören (für NFS bleistiftsweise). Ansonsten wäre mein erster Verdacht, dass AppArmor halt das ptrace im Container blockt. Stelle AppArmor mal auf Logging, falls nötig, und gucke, ob da im Log entsprechende Fehlermeldungen auftauchen.

Ich vermute, dass die Prozesse, die er anzeigt, die sind, die im Container selbst laufen. Und die anderen laufen außerhalb und werden deshalb geblockt. Natürlich weiß ich nicht, wie du deinen Container eingerichtet hast, aber Port 111 ist ja z.B. der Portmapper, welcher bei aktuellen Distros von SystemD gestellt wird. Und der Init-Prozess dürfte dem Host gehören.

[Lookbehind]

Hi foobar, danke für deine Antwort! Das hat tatsächlich geholfen.

Naja, grundsätzlich muss nicht jeder offene Port auch mit einem Prozess verbunden sein. Ein Klassiker sind Ports, die keinem Prozess, sondern dem Kernel gehören (für NFS bleistiftsweise).

Ja, die kenn ich wohl. Aber ich kann dir versichern, dass mindestens Port 25565 nicht vom Kernel bereit gestellt wird. (Ausgerechnet in einem Gaming-Forum könnte man den kennen )

Ansonsten wäre mein erster Verdacht, dass AppArmor halt das ptrace im Container blockt. Stelle AppArmor mal auf Logging, falls nötig, und gucke, ob da im Log entsprechende Fehlermeldungen auftauchen.

ptrace! Na klar! Da hatte ich wieder Tomaten auf den Augen!

CAP_SYS_PTRACE
* Trace arbitrary processes using ptrace(2);
* apply get_robust_list(2) to arbitrary processes;
* transfer data to or from the memory of arbitrary processes us-
ing process_vm_readv(2) and process_vm_writev(2);
* inspect processes using kcmp(2).

Ich hab ein Test-Setup in einer VM aufgezogen und den Container da nochmal deployet. Und, welch Überraschung, wenn ich die Capability erlaube gehts auch.

Danke für den Schubser.

Ich vermute, dass die Prozesse, die er anzeigt, die sind, die im Container selbst laufen. Und die anderen laufen außerhalb und werden deshalb geblockt. Natürlich weiß ich nicht, wie du deinen Container eingerichtet hast, aber Port 111 ist ja z.B. der Portmapper, welcher bei aktuellen Distros von SystemD gestellt wird. Und der Init-Prozess dürfte dem Host gehören.

Knapp daneben ist auch vorbei. Die laufen tatsächlich alle IN dem Container. ... Docker ist nicht die einzige Container-Runtime