Narazil jsem na stejný problém a na začátku jsem si myslel totéž jako výše, že možná gdb ignoruje schopnost spustitelného souboru z bezpečnostních důvodů. Nicméně čtení zdrojového kódu a dokonce i použití eclipse ladění samotného gdb, když ladí můj ext2fs-prog, který otevírá /dev/sda1
, Uvědomuji si, že:
- gdb není speciální jako jakýkoli jiný program. (Stejně jako v matrixu, i samotní agenti se řídí stejnými fyzikálními zákony, gravitací atd., kromě toho, že jsou všichni strážci dveří.)
- gdb není nadřazeným procesem laděného spustitelného souboru, ale je hlavním otcem.
- Skutečným nadřazeným procesem laděného spustitelného souboru je „shell“, tj.
/bin/bash
v mém případě.
Řešení je tedy velmi jednoduché, kromě přidání cap_net_admin,cap_net_raw+eip
na gdb, musíte to také použít na svůj shell. tj. setcap cap_net_admin,cap_net_raw+eip /bin/bash
Důvod, proč to musíte udělat také pro gdb, je ten, že gdb je nadřazený proces /bin/bash
před vytvořením laděného procesu.
Skutečný spustitelný příkazový řádek v gdb vypadá takto:
/bin/bash exec /my/executable/program/path
A toto je parametr pro vfork uvnitř gdb.
Pro ty, kteří mají stejný problém, můžete tento problém obejít spuštěním gdb pomocí sudo.
Před chvílí jsem narazil na stejný problém. Domnívám se, že spuštění laděného programu s dalšími funkcemi je bezpečnostní problém.
Váš program má více oprávnění než uživatel, který jej spouští. Pomocí debuggeru může uživatel manipulovat s prováděním programu. Pokud tedy program běží pod debuggerem s extra oprávněními, pak by uživatel mohl tato oprávnění použít pro jiné účely, než pro které je program zamýšlel používat. To by byla vážná bezpečnostní díra, protože uživatel na prvním místě nemá oprávnění.