gdb は実行可能機能を無視しているようです

私は同じ問題に遭遇し、最初はセキュリティ上の理由から gdb が実行可能ファイルの機能を無視している可能性があると考えました。ただし、ソースコードを読み取り、 /dev/sda1 を開く ext2fs-prog をデバッグしているときに、Eclipse デバッグ gdb 自体を使用することさえあります 、次のことに気付きました:

<オール>

gdb は他のプログラムのように特別なものではありません。 (マトリックスにあるように、エージェント自身も同じ物理法則、重力などに従いますが、すべてドアキーパーであることを除きます。)

gdb はデバッグされた実行可能ファイルの親プロセスではなく、親プロセスです。

デバッグされた実行可能ファイルの真の親プロセスは「シェル」、つまり /bin/bash です。 私の場合

cap_net_admin,cap_net_raw+eip を追加することを除けば、解決策は非常に単純です。 gdb に、これをシェルにも適用しました。すなわち setcap cap_net_admin,cap_net_raw+eip /bin/bash

gdb に対してもこれを行う必要があるのは、gdb が /bin/bash の親プロセスであるためです。 デバッグされたプロセスを作成する前に。

gdb 内の実際の実行可能なコマンド ラインは次のようになります:

/bin/bash exec /my/executable/program/path

そして、これは gdb 内の vfork へのパラメーターです。

同じ問題を抱えている人は、sudo を使用して gdb を実行することで、この問題を回避できます。

少し前に、私は同じ問題に遭遇しました。私の推測では、追加機能を使用してデバッグ済みプログラムを実行することは、セキュリティ上の問題であると思われます。

プログラムには、それを実行するユーザーよりも多くの特権があります。デバッガーを使用すると、ユーザーはプログラムの実行を操作できます。そのため、プログラムが追加の特権を使用してデバッガーの下で実行される場合、ユーザーはこれらの特権を、プログラムが使用する目的以外の目的で使用できます。そもそもユーザーが権限を持っていないため、これは重大なセキュリティ ホールとなります。