Benutzer kann nicht pingen - Kernel config?

[JTH]

Mal eine ganz praktische Idee zwischendurch: Meckert ping vielleicht nicht, wenn du explizit nur IPv4 verwendest?

Code: Alles auswählen

ping -4 1.2.3.4

Ohne in den Code geschaut zu haben vermute ich mal, dass dann im Programmablauf kein Socket mit AF_INET6 geöffnet wird.

Nachtrag:
Sollte so sein, wie oben vermutet. [1] [2] [3]

[fischig]

Da ich nicht wusste, was ich hätte tun können, um einen bullseye-Standard-Kern bootbar nachzuinstallieren, habe ich erst mal eggys Variante b probiert. Selbstbau-Kern mit ipv6 und ipv6_sit fest im Kern einkompiliert (ipv6_sit wurde als einziges „Unter"modul für ipv6 von make menuconfig direkt vorgeschlagen). Die erste Meldung

Code: Alles auswählen

ping: socket: Die Adressfamilie wird von der Protokollfamilie nicht unterstützt

ist mit diesem Kern weg, aber nach wie vor kann nur root pingen. Beim Benutzer kommt:

Code: Alles auswählen

socket: Die Operation ist nicht erlaubt

Wenn ich die Kommentare hinter JTHs Links verstanden habe, ist das für das Kommando ping auch so gewollt?

Frage: ist das neu in bullseye?
Wenn ich etwas fehlkonfiguriert habe, stelle ich das gerne ab. auf den User-ping möchte ich ungern verzichten. Das ist für mich immer der erste Versuch, zu testen ob eine Netzverbindung funktioniert - mehr nicht. Dazu sollte ich kein root sein müssen, denke ich.

Ich probierte ja auch gerne eggys Variante a
aber dann sollte mir jemand Tipps geben, wie ich in der gegebenen Situation zu einem bootfähigen Standard-Kern kommen könnte.

Code: Alles auswählen

# ls -l /bin/ping
-rwxr-xr-x 1 root root 80176  2. Feb 2021  /bin/ping

# /sbin/getcap /bin/ping
Failed to get capabilities of file '/bin/ping' (Operation not supported)

(alter Zustand, also Selbstbau-Kern 5.10 ohne ipv6)

@wanne

Es gibt aber genug, die wie du aus Ideologie oder Sicherheitsgrüden IPv6 möglichst gewaltsam abschalten

Volltrottel [...], die zuerst IPv6 verkrüppeln und sich dann über die Folgen wundern

Geht's auch weniger unterstellend und beleidigend?

[JTH]

Wenn ich die Kommentare hinter JTHs Links verstanden habe, ist das für das Kommando ping auch so gewollt?

Mein Einwurf bezog sich nur auf dein ursprüngliches Problem zur nicht unterstützten Protokollfamilie, als pragmatische „Lösung“ ohne Ursachensuche. Ich geb zu, die restlichen Beiträge vorhin nur überflogen zu haben.

Beim Benutzer kommt:

Code: Alles auswählen

socket: Die Operation ist nicht erlaubt

[…]
Frage: ist das neu in bullseye?

Nein, das ping auf einem von zwei möglichen Wegen (setcap, setuid) für unpreviligierte Benutzer extra Rechte bekommt, ist sicher nicht soo neu. Siehe dazu das Ende von wannes letztem Beitrag.

Code: Alles auswählen

# /sbin/getcap /bin/ping
Failed to get capabilities of file '/bin/ping' (Operation not supported)

(alter Zustand, also Selbstbau-Kern 5.10 ohne ipv6)

Vermutlich fehlt dir auch da in deinem Selbstbaukernel etwas relevantes – obwohl die Capabilities laut man capabilities seit Kernel 2.6.33 ohne extra CONFIG_sowieso immer eingebaut sein sollen. Stecke da aber nicht im Detail drin, klinke mich hier wieder aus.

[eggy]

Du könntest ja mal Deine config Posten (und den Titel editieren "Benutzer kann nicht pingen - liegts an der Kernel config?"), vielleicht schauen dann noch Leute drauf, die sich mehr für Kernelthemen interessieren.

Kleine Frage am Rande, Du schreibst /sbin/getcap. Die getcap Kommandos hast Du als root abgesetzt (und falls ja, mit "su" oder "su-")?
Nicht, dass wir hier mal wieder eine weitere Ausgabe unserer Lieblingsproblemursache vor uns haben

[wanne]

Geht's auch weniger unterstellend und beleidigend?

Das ist nicht beleidigend sondern entspricht einfach den Tatsachen.

Kleine Frage am Rande, Du schreibst /sbin/getcap. Die getcap Kommandos hast Du als root abgesetzt (und falls ja, mit "su" oder "su-")?

Das war ich, weil getcap zwar unter /sbin liegt aber problemlos als normaler User funktionieren sollte.

Code: Alles auswählen

# ls -l /bin/ping
-rwxr-xr-x 1 root root 80176  2. Feb 2021  /bin/ping

# /sbin/getcap /bin/ping
Failed to get capabilities of file '/bin/ping' (Operation not supported)

(alter Zustand, also Selbstbau-Kern 5.10 ohne ipv6)

Für mich sieht das nach einem ähnlichen Problem aus wie zuvor. Debian prüft zwar ab, ob libcap2 und Abhängigkeiten vorhanden sind. Rechnet aber natürlich nicht mit einem Kernel, der das nicht kann. – Wie gesagt: Seit 2.6.33 ist das überall drin. Irgend wann verlassen sich die Leute drauf.
Du kannst das mit chmod +s /bin/ping fixen. Dann läuft ping aber halt wie früher immer mit vollen root-Rechten. Und jedes Update wird das wieder zerstören.
Alternativ kannst du libcap2 deinstallieren. Dann kapiert debian, dass es keine capabilities gibt. Wenn du dann iputils neu installierst wird apt das zumindest für ping automatisch fixen. – So lange bis das nächste Programm über deinen krüppelkernel stolpert.
Alles wird nicht den ursprünglichen Fehler (ping: socket: Die Adressfamilie wird von der Protokollfamilie nicht unterstützt) beheben. Der gehört so.

aber dann sollte mir jemand Tipps geben, wie ich in der gegebenen Situation zu einem bootfähigen Standard-Kern kommen könnte.

Vermutlich apt-get install linux-image-amd64? – Ich muss natürlich wieder raten, weil du mir noch immer kein uname -a gegeben hast.
Alternativ: Debian compiliert mit den Optionen: pastebin/?mode=view&s=41433
Abgesehen von gewisser Hardware solltest du auch kein Problem mit den vanilla-Optionen haben. Du hast aber offensichtlich ein Haufen Zeug geändert, von denen du die Folgen nicht abschätzen konntest.

[JTH]

Code: Alles auswählen

# /sbin/getcap /bin/ping
Failed to get capabilities of file '/bin/ping' (Operation not supported)

(alter Zustand, also Selbstbau-Kern 5.10 ohne ipv6)

Wenn ich doch nochmal mitgrübeln darf: Deinem Kernel fehlen vielleicht erweiterte Dateiattribute: Can't get or set file capabilities.

[fischig]

Vermutlich apt-get install linux-image-amd64?

Sollte das auf der alten Maschine (TP X31) nicht eher linux-image-686 sein?

Code: Alles auswählen

# uname -a
Linux x31 5.10.26-x31.0 #5.10.26 SMP PREEMPT Sat Mar 27 22:07:33 CET 2021 i686 GNU/Linux

Du schreibst /sbin/getcap. Die getcap Kommandos hast Du als root abgesetzt (und falls ja, mit "su" oder "su-

weder noch: direkt als root, eingeloggt auf tty1.

die config: pastebin/?mode=view&s=41434

[JTH]

die config: pastebin/?mode=view&s=41434

Wenn ich das richtig sehe – ich finde die Zusammenhänge mancher CONFIG_* nicht leicht nachzuschlagen – wären hier die CONFIG_<filesystem>_FS_SECURITY und (außer bei ext4) CONFIG_<filesystem>_FS_XATTR notwendig, damit getcap/setcap auf dem jeweiligen Dateisystem funktioniert.

[fischig]

Wenn ich das richtig sehe [...] wären hier die CONFIG_<filesystem>_FS_SECURITY und (außer bei ext4) CONFIG_<filesystem>_FS_XATTR notwendig

Erst mal vielen herzlichen Dank! Das scheint's gewesen zu sein.
Der Benutzer darf jetzt pingen.

Code: Alles auswählen

# /sbin/getcap /bin/ping
/bin/ping cap_net_raw=ep

Ich hatte das schon bei deinem gentoo-Link ins Auge gefasst (ich kann mich zwar nicht mit der wissenschaftlichen Kompetenz von wanne messen, aber soviel Englisch geht dann doch), wollte aber erst mal warten, ob noch andere Ideen kommen.

Erklären, wie's zustande kekommen ist, kann ich mir's nicht.
In der Regel baue ich meine Kerne so, dass, wenn ich keine geeignete config habe (die vom Standard-Kern herzunehmen, halte ich für mich für sinnlos. Ich wäre mit den ca 8000-Config-Zeilen hoffnungslos überfordert), ich mir eine via defconfig erzeuge und dann das Erforderliche gezielt nachinstalliere. Diese config rüste ich dann wiederum via oldconfig gezielt nach bei jedem Release-/Kernel-Wechsel. Auf eine ähnliche Weise ist also also auch der hier zur Diskussion stehende Kern entstanden, jedenfalls habe ich nicht „ein Haufen Zeug geändert, von [dem ich] die Folgen nicht abschätzen konnte.“ Ich habe das Phänomen seit über 10 Jahren noch bei keinem anderen selbstgebauten Kern gesehen.
Ich habe nur noch eine andere i386-Maschine, aber die ist mit devuan beowulf ~ Debian buster bestückt. Auch dort hat der auf die gleiche Weise gebaute Selbstbau-Kern 4.19 kein ext_4_fs_security und trotzdem darf der Benutzer pingen.
In dem auf TP X61 laufenden Selbstbau-Kern 4.19 mit buster ist ext4_fs_security einkompiliert.

[JTH]

Der Benutzer darf jetzt pingen.

Jut.

Ich habe nur noch eine andere i386-Maschine, aber die ist mit devuan beowulf ~ Debian buster bestückt.

Da möchte ich dich an ein entsprechendes Forum verweisen Ne, Scherz beiseite:

Erklären, wie's zustande kekommen ist, kann ich mir's nicht.

iputils-ping hängt erst seit einer Version nach Buster hart von libcap2-bin ab. Vorher war es nur ein Recommends und ist vielleicht auf deinem einen System daher nicht installiert. In letzterem Fall fällt das iputils-ping-Paket auf setuid zurück. Könntest du mit einem ls -l /bin/ping mal nachgucken. Statt einem x taucht dann ein s in den Dateiberechtigungen auf.

[fischig]

Code: Alles auswählen

# ls -l /bin/ping
-rwsr-xr-x 1 root root 72096 Jan 14  2020 /bin/ping

Deine Links funktionieren hier nicht, weder mit palemoon noch mit firefox-esr unter buster:

Code: Alles auswählen

something went wrong (500)

Und nochmals vielen Dank für die sachkundige Aufklärung!

[off topic]:

Da möchte ich dich an ein entsprechendes Forum verweisen

Tät ich ja glatt zusätzlich.
Aber dazu reichen meine IT-fachsprachlichen Englischkenntnisse nun wirklich nicht und in diesem Leben wird das auch nix mehr.
[/off topic]

edit:
Was mache ich jetzt mit ipv6?
Für die Problemlösung war es ja wohl irrelevant - richtig?
Aber mal abgesehen davon, ob ich die vollständige Ersetzung von ipv4- durch ipv6-Adressen noch erleben werde, sind wannes diesbezüglichen Überlegungen in der Sache ja nicht von der Hand zu weisen.

[wanne]

Geht's auch weniger unterstellend und beleidigend?

Um das nochmal klar zu stellen: Das hat nicht gegen fischig gezielt, der Probleme hat und die Lösen will. Und ich dachte eigentlich, dass der das auch versteht. Ich ärgere mich aber über Entwickler, die ihre selbst produzierten Probleme zu denen anderer erklären.

Für die Problemlösung war es ja wohl irrelevant - richtig?

Für das in der Überschrift ja. Die Fehlermeldung wird bleiben.

sind wannes diesbezüglichen Überlegungen in der Sache ja nicht von der Hand zu weisen.

Am Ende musst du das selber wissen. Am ende macht IPv6 den Kernel wirklich fetter und IPv4 abschalten ist defakto keine Option (Man könnte NAT64 oder ähnliche Konstrukte fahren... Wollen tut man das sicher nicht.). Ich muss selbst zugeben dass ich noch nen AP mit 4.14? Kernel und deaktiviertem IPv6 rum fahren habe, weil ich das anders leider wirklich nicht in die 2MiB-Flash rein bekomme und neue Hardware kaufen ist mir dann doch zu schade...

[fischig]

Und ich dachte eigentlich, dass der das auch versteht.

Dann hätt'ste mich schon etwas deutlicher separieren müssen.

Es waren halt zwei getrennte Problemchen und das habe ich als Laie anfangs nicht erkannt.

„Protokollfamilie“ hing wohl mit IPV6 zusammen. Das hast du mir beigebracht
User-Ping hing mit ext4_fs_security zusammen, das hat JTH mir beigebracht.

Alles gut, wanne!

[fischig]

Ich will das nochmal hochspülen. Nach dem Upgrade auf bullseye auf einer anderen Maschine (diesmal amd64) hatte ich wieder das Problem mit der Verweigerung des Pings für den User. Obwohl alle hier genannten Pakete bereits installiert waren. ext4_fs_security war fest im Eigenbau-Kern 5.10 für diese Maschine. Das einzige, was fehlte, war config_ipv6 im Kern. Habe ich nachkompiliert. Trotzdem konnte der User nach wie vor nicht pingen. Das Kommando

Code: Alles auswählen

/sbin/getcap /bin/ping

brachte keine Ausgabe, auch keinen Fehler. Dann habe ich

Code: Alles auswählen

setcap cap_net_raw=ep /bin/ping

ausgeführt. Erst dann konnte der User pingen. Wenn ich recht erinnere, dann musste ich das beim bisher diskutierten System (i386) nicht machen (setcap ausführen). Jetzt bin ich erneut verwirrt. Ist das jetzt so in Ordnung? Beziehe mich bei meinen Zweifeln auf diese Vermutung JTHs:

Vermutlich fehlt dir auch da in deinem Selbstbaukernel etwas Relevantes – obwohl die Capabilities laut man capabilities seit Kernel 2.6.33 ohne extra CONFIG_sowieso immer eingebaut sein sollen.

[JTH]

Ist das jetzt so in Ordnung?

Wenn ping jetzt funktioniert wie erwartet, wird es wohl so okay sein. Ansonsten fällt mir direkt kein offensichtlicher Grund ein, warum das manuelle setcap notwendig war. Solange der während des Upgrades laufende Kernel die notwendigen Configs eingebaut hatte, wird das setcap auch beim Paketupgrade von iputils-ping ausgeführt.