Ich stoße auf dasselbe Problem und am Anfang dachte ich dasselbe wie oben, dass gdb möglicherweise aus Sicherheitsgründen die Fähigkeit der ausführbaren Datei ignoriert. Lesen Sie jedoch den Quellcode und verwenden Sie sogar das Eclipse-Debugging von gdb selbst, wenn es mein ext2fs-prog debuggt, das /dev/sda1 öffnet , das ist mir klar:
- gdb ist nichts Besonderes wie jedes andere Programm. (Genau wie in der Matrix gehorchen auch die Agenten selbst demselben physikalischen Gesetz, der Schwerkraft usw., außer dass sie alle Türhüter sind.)
- gdb ist nicht der übergeordnete Prozess der debuggten ausführbaren Datei, sondern der Großvater.
- Der eigentliche übergeordnete Prozess der debuggten ausführbaren Datei ist "shell", d.h.
/bin/bashin meinem Fall.
Die Lösung ist also sehr einfach, abgesehen vom Hinzufügen von cap_net_admin,cap_net_raw+eip auf gdb müssen Sie dies auch auf Ihre Shell anwenden. also setcap cap_net_admin,cap_net_raw+eip /bin/bash
Der Grund, warum Sie dies auch für gdb tun müssen, ist, dass gdb ein übergeordneter Prozess von /bin/bash ist vor dem Erstellen eines debuggten Prozesses.
Die echte ausführbare Befehlszeile innerhalb von gdb sieht wie folgt aus:
/bin/bash exec /my/executable/program/path
Und dies ist ein Parameter für vfork innerhalb von gdb.
Für diejenigen, die das gleiche Problem haben, können Sie dieses umgehen, indem Sie gdb mit sudo ausführen.
Vor einiger Zeit bin ich auf das gleiche Problem gestoßen. Meine Vermutung ist, dass das Ausführen des debuggten Programms mit den zusätzlichen Fähigkeiten ein Sicherheitsproblem darstellt.
Ihr Programm hat mehr Rechte als der Benutzer, der es ausführt. Mit einem Debugger kann ein Benutzer die Ausführung des Programms manipulieren. Wenn das Programm also unter dem Debugger mit den zusätzlichen Privilegien läuft, könnte der Benutzer diese Privilegien für andere Zwecke verwenden, als für die das Programm sie beabsichtigt hatte. Dies wäre eine ernsthafte Sicherheitslücke, da der Benutzer die Privilegien gar nicht erst hat.