Benutzer kann nicht pingen - Kernel config?

[fischig]

Ich habe hier ein minimalistisch installiertes bullseye, an dem der Benutzer nicht pingen kann:

Code: Alles auswählen

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

Als root erscheint die gleiche Meldung, aber der ping läuft.

[wanne]

Schuss ins Blaue:

Code: Alles auswählen

apt install iputils-ping; apt purge inetutils-ping

Sonst. Was sagt:

Code: Alles auswählen

ping -V

[fischig]

iputils-ping ist bereits istalliert.

[fischig]

ping -V sagt:

Code: Alles auswählen

ping from iputils 210202

Sowohl als root als auch als Benutzer.

[eggy]

dann mal andersrum probieren

Könnte das hier sein: https://github.com/iputils/iputils/issues/293

[wanne]

Interessant. Bei mir sieht das so aus:

Code: Alles auswählen

/bin/ping -V
ping utility, iputils-s20180629

Auf was pingst du denn?
Kannst du mal die volle Ausgabe posten. (+ relevante Einträge in der /etc/hosts)
Interessant wäre auch dasda:

Code: Alles auswählen

ls -l /bin/ping
/sbin/getcap /bin/ping

Könnte das hier sein: https://github.com/iputils/iputils/issues/293

Wäre auch meine Vermutung gewesen. Aber Debian hat seit mindestens Etch keine Kernels ohne IPv6 support.
Aber zur sicherheit: Was sagt den

Code: Alles auswählen

uname -a
ls -ld /proc/sys/net/ipv6/
cat /boot/config-$(uname -r)

Eventuell:

Code: Alles auswählen

cat /proc/sys/net/ipv6/conf/*/disable_ipv6
ip -6 r

Das sollte aber kein Problem sein.

dann mal andersrum probieren

Das willst du glaube ich eher nicht machen. Auch wenn es das "Problem" behebt.

[eggy]

@wanne: war nicht als Lösung, sondern als weiter Ansatz zur Problemerkenntnis gedacht. In dem verlinkten Thread gab's ja einige Ideen, denen man nachgehen könnte. Liegt's am Kernel (vielleicht ein Selbstbaukernel), strace mal mitlaufen lassen, wo stammt die Meldung her, ältere Version installieren und schauen, ob sich was ändert, etc. Auch anderes "ping" ausprobieren könnte weitere neue Ideen bringen. Und an iptables/nftables oder Berechtigungen auf dem net-dev wirds ja eher nicht liegen, aber auch in der Richtung könnt man aus Verzweiflung noch schauen.

[fischig]

Hinter eggys Link gibt's zuviel Fachenglisch für mich.

Womit ich nicht gerechnet hätte: es ist ein Eigenbaukern. Ich habe jetzt einen Standard-Kern: linux-image-5.10.0-8-686 reinstalliert, aber der bootet nicht durch:

Code: Alles auswählen

/scripts/local-premount/resume: line 383: blkid: not found

Wenn ihr mit dieser Fehlermeldung etwas anfangen könnt: Soll ich mit den anderen geforderten Ausgaben warten oder soll ich die unter laufendem Eigenbau-Kern posten?

[eggy]

Dass da nen fehlendes blkid angemeckert wird, könnte daran liegen, dass util-linux nicht installiert ist. Wie "minimal" soll das System denn bleiben?

[fischig]

Wie "minimal" soll das System denn bleiben?

konsole, X, openbox, tint2 kein Browser.

Mir ist bisher gar nichts aufgefallen. Ich kann aus den Repos installieren, ich kann nfs-Freigaben im LAN einhängen.

edit: util-linux war's wohl nicht. Die Meldung kommt immer noch.

edit2: unter Eigenbaukern 5.10:

Code: Alles auswählen

# ls -ld /proc/sys/net/ipv6/
ls: Zugriff auf '/proc/sys/net/ipv6/' nicht möglich: Datei oder Verzeichnis nicht gefunden

edit3:
Noch ein paar für mich merkwürdige Beobachtungen

Der Rechner heißt x31, IP 192.168.100.159. Versuche ich mich vom Rechner namens x61 mit IP 192.168.100.151 via ssh [Benutzer]@x31 einzuloggen, kriege ich:

Code: Alles auswählen

ssh: connect to host x31 port 22: no route to host

Versuche ich's via ssh [Benutzername]@192.168.100.159, bin ich umgehend eingeloggt.

Weiter:
User-Ping von x61 auf x31
Ein paar mal versucht er das hier:

Code: Alles auswählen

From router.[domain] (192.168.100.251): icmp_seq=2 Redirect Host(New nexthop: drk-srv (192.168.100.110))

bevor er abbricht mit

Code: Alles auswählen

Destination Host Unreachable

Ich hatte x31 (mit demselben Namen) vor Zeiten mal in einem anderen Subnetz, das nur über /
192.168.100.251 (Router-IP)/192.168.100.110 erreichbar war.

User-Ping von x61 auf 192.168.100.159: keine Fehler

[wanne]

edit2: unter Eigenbaukern 5.10:

Code: Alles auswählen

# ls -ld /proc/sys/net/ipv6/
ls: Zugriff auf '/proc/sys/net/ipv6/' nicht möglich: Datei oder Verzeichnis nicht gefunden

Ja. Der Kernel ist kaputt.
Mich würde das interessieren:

Code: Alles auswählen

uname -a
cat /boot/config-$(uname -r)

bzw. deine .config beim Compilen des Kernels.

[eggy]

Ja. Der Kernel ist kaputt.

Ich würde sagen, der hat einfach kein v6.
Wollen wir nicht erstmal klären, ob (bzw aus welchem Grund) da am Ende nen Custom Kernel drauf sein soll, oder ob die Diagnose in Bezug auf den Debianischen erstmal der sinnvollere Schritt wäre?

[fischig]

Da bisher auf eggys Frage niemand angesprungen ist:
Ich bin kein Experte, aber ich bezweifle, dass ich ipv6 benötige. Ich habe das jetzt mal mit anderen in meinem LAN laufenden Selbstbau-Kern-Konfigurationen verglichen, bei denen ich auch kein ipv6 einkompiliert habe und die den Fehler nicht aufweisen. Das sind allerdings keine bullseye-Systeme mit grub.

Für mich sieht das eher nach einem Rechte-Problem aus? Der ping funktioniert ja - als root ausgeführt.

[eggy]

Da bisher auf eggys Frage niemand angesprungen ist:
Ich bin kein Experte, aber ich bezweifle, dass ich ipv6 benötige. Ich habe das jetzt mal mit anderen in meinem LAN laufenden Selbstbau-Kern-Konfigurationen verglichen, bei denen ich auch kein ipv6 einkompiliert habe und die den Fehler nicht aufweisen. Das sind allerdings keine bullseye-Systeme mit grub.

Für mich sieht das eher nach einem Rechte-Problem aus? Der ping funktioniert ja - als root ausgeführt.

Auch wenn man selbst kein v6 braucht, kann es sein, dass bestimmte Tools einfach davon ausgehen, dass es v4 und v6 gibt.
Falls Dein ping versucht sowohl v4 als auch v6 zu nutzen und der Kernel antwortet ihm "v6? nie gehört?!" und das Programm fängt das dann nicht ordentlich ab, dann hättest Du genau diese Situation: es funktioniert (v4) aber gleichzeitig gibt es auch eine Meldung (v6).
Das ist ja auch das Szenario, über das in dem Bugreport teilweise diskutiert wird, ob das nun der Fall ist oder nicht, müsste man mal herausfinden. Und das geht meiner Meinung nach am "einfachsten", in dem man nen Kernel mit v6 nimmt.
Und dafür gibt's zwei Optionen:
a) Debiankernel der ja schon v6 hat ... und wenn es da Fehler gibt, die erstmal loswerden
b) nochmal testweise Kernel bauen, mit v6 ... und schauen was sonst noch alles kaputt ist

[wanne]

Ich würde sagen, der hat einfach kein v6.

Und IPv4 ohne IPv6 Support ist halt kaputt. Der Standard sagt seit weit über 20 Jahren, dass du auf neuen Systemen zuerst IPv6 und dann IPv4 probieren sollst. In in einem System in dem es kein IPv6 gibt (disabled, kein Netz) ist das klein Problem. - Selbst wenn du nur IPv6-Code schreibst. Der Linux-Kernel macht in den meisten Fällen ohne Zutun der Anwendung automatischen Fallback auf IPv4. Alternativ kann die Anwendung selbst reagieren. Hast du IPv6 nicht einkompiliert, kann dir der Kernel halt nicht mal mehr eine vernünftige Fehlermesssage geben. Er sagt halt nur: Verstehe ich nicht... Damit kann wiederum die Anwendung nichts anfangen. Das Verhalten ist komplett korrekt. Im Bugreport wurde vorgeschlagen wie viele andere Anwendungen als erstes abzufangen ob der Kernel überhaupt mit IPv6 umgehen kann. Es ist aber IMHO völliger Unsinn in jede Anwendung etwas einzubauen, was eh schon im Kernel ist und sowieso eigentlich nicht existieren dürfte. (Praktisch kein modernes Tool dürfte auf nem 1.3er Kernel. Alle anderen sind offensichtlich nach der IPv6 Einführung geschrieben.)

Ich bin kein Experte, aber ich bezweifle, dass ich ipv6 benötige.

Das ist so ne Frage. Guck dir mal die Spieltheoretische Idee hinter evolutionärem Selbstmord an:
Prinzipiell gilt:
* IPv4 hat diverse Sicherheitsprobleme deren Workarounds mehrfach zu Sicherheitslücken geführt haben. IPv6 wurde mit Security in Mind desighned.
* IPv4 Routing ist in praktisch jedem Fall deutlich ineffizienter als IPv6 Routing.
* IPv6 Programme können unter Windows und Linux automatisch IPv4 aber nicht umgekehrt. => Es ist sinnvoller für IPv6 zu entwickeln für reine Windows Programme wird das auch häufig gemacht, weil sich dort (Standardkonform) nur IPv4 oder beides aber nicht IPv6 alleine abschalten lässt.
Genau deswegen wurde in den Standard geschrieben, dass man zuerst IPv6 machen soll. Die Hoffnung war, dass man nach ein Paar Jahren IPv4 los ist und dann ein deutlich besseres System hat.
Für den einzelnen gilt aber:
* IPv4+IPv6 hat natürlich mehr Sicherheitslücken als IPv4 alleine.
* IPv6+IPv4 ist aufwändiger zu konfigurieren. Das was IPv6 an Strom und Hardware einspart, wiegt das für kleine Betreiber nicht auf. Für große Betreiber ist eine individuelle Abrechnung teurer als einfach pauschal für beides zu verlangen
* So lange es Systeme mit deaktiviertem IPv6 gibt, muss jedes Programm zusätzlich zum Universellen halt doch einen reinen IPv4 Variante einbauen.
Prinzipiell gilt also global: IPv6 > IPv4 > Dualstack.

Entsprechend entwickelt sich folgende Dynamik:
* Anbieter die mit Anbietern oder Kunden zusammen arbeiten, die nur IPv4 können müssen, müssen eh IPv4 machen. – Ursprünglich nahm man deswegen an, dass die die letzten sein werden, die umstellen, wenn sie ihre Hardware austauschen und dann sparen können.
* Nutzer haben erst mal keinen Vor- oder Nachteil von irgend einer Variante. – Man nahm also an, dass die als erstes auf Dualstack umsteigen, wenn man das in den Standard schreibt. Die meisten haben das auch gemacht. Es gibt aber genug, die wie du aus Ideologie oder Sicherheitsgrüden IPv6 möglichst gewaltsam abschalten, solange all ihre Software tut haben sie Individuell davon keinen Nachteil. – Im Krassen Gegensatz zu Leuten die IPv4 abschalten: Es gibt noch immer massenhaft Software, die nur IPv4 kann.
* Softwareanbieter würden von Dualstack profitieren, weil sie dann nur noch ein mal Code schreiben müssten und nicht doppelt. Aber sie würden Nutzer verlieren, wenn ihre Software in reinen IPv4-Umgebeungen nicht funktioniert. (Bzw. schlimmer mit Bugreports von denen zugespammt werden) Deswegen hat fast jede Software 2 Codepfade einen für IPv4 und einen für IPv6 oder Dualstack. Immer mehr machen auch nur IPv4. Damit spart man sich auch den 2. Codepfad und Nutzer die IPv4 abgeschaltet haben gibt es defakto nicht.
Fettestes Beispiel: Python hatte lange im Netzwerkbeispiel Dualstack und das jetzt ausdrücklich durch (längeren) IPv4 only Code ausgetauscht, weil es zu viele Nutzer kaputt konfigurierten IPv4-Only Systemen hatten, die dann von den Fehlern verwirrt waren. Sie erwähnen sogar das seit 30 Jahren tote X25 (der europäische IP Vorgänger) haben aber alle IPv6 Erwähnungen raus genommen weil es genug Volltrottel rumlaufen, die zuerst IPv6 verkrüppeln und sich dann über die Folgen wundern.

In Kurz: Du hast erst mal selbst kein Problem. Die paar Leute mit Konfigurationen wie du machen dem ganzen Rest aber riesige Probleme. Man sieht das ganze auch schön bei Facebook. Innen wo sie die Kontrolle haben, machen sie seit langem IPv6 only Nach außen hatten sie aber sogar lange einige IPv4 only-Server rumstehen.

Wie gesagt: Das Problem ist häufig. Wir haben das auch mit opus/aac vs. mp3 oder HDMI vs. DP oder tcp vs. SCTP oder jpeg vs. WebP.
Jeweils gibt es einmal das in jeglicher Hinsicht Bessere und ein mal das Ältere. Sogar in extremfällen wie mp3 wo mp3 nur wenige Jahre älter als aac ist und AAC bei gleicher Bitrate weit bessere Qualität liefert hat sich der schlächtere aber ältere Standard durchgesetzt.
Auf der anderen Seite Gibt es natürlich weit mehr Gegenbeispiele, wo die Vernunft siegte und sich auf die dauer das bessere durchgesetzt hat. SCART vs. HDMI; IP vs. X25...

Für mich sieht das eher nach einem Rechte-Problem aus? Der ping funktioniert ja - als root ausgeführt.

Indirekt. Ping braucht eigentlich root-Rechte macht Dinge, die Nutzer nicht dürfen und bekommt einen Haufen Informationen, die normale Nutzer nicht sehen dürfen. Deswegen wird ping traditionell* als root ausgeführt aber wenn es vom Nutzer aufgerufen wurde läuft es in reduziertem Umfang und gibt deutlich weniger Informationen aus. (Damit Nutzer keinen Schmu treiben können.) Defakto sind das also 2 ziemlich unterschiedliche Programme, die sich unterschiedlich verhalten. Beide laufen auf den selben Fehler. Nur das eine beendet sich dann halt das andere macht mit IPv4 weiter. So verwunderlich finde ich beide verhalten nicht.

* Klassisch mit SUID Bit. Mittlerweile kenn Linux so ne Art Teil-Rootrechte: capabilities net_raw gibt dir grob die Möglichkeit im Netzwerk alles zu machen, was root darf (An der Firewall vorbei auf verbotenen Ports als fremdes Programm verschicken...) sonst nicht. Debian verwendet im Normalfall die letzte Variante. Auf einem wirklich krass minimalistischen System, dass keine capabilities ändern kann, nutzt es weiter SUID. Deswegen hätte ich gerne das gehabt. Das ist echt nerfig mit dem Raten mit Rosental, was du da hast:

Code: Alles auswählen

ls -l /bin/ping
/sbin/getcap /bin/ping

[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.