注：これは部分的にプログラミングに関する質問ですが、私の直感的には、これがLinuxのセキュリティ機能フレームワークとより関連しているということです。一般的に言えばしたがって、StackOverflowの代わりにここに投稿してください。
生のソケットとパケットキャプチャを使用する必要があるプログラムがありますcap_net_raw。私が使っているシステムはDebian 11とLinux 5.16.0-6-amd64です。
cap_net_adminバイナリに機能を付与しました( )
% sudo /sbin/setcap 'cap_net_raw,cap_net_admin+eip' ./program
（注：ユーザーcap_setfcapに機能を付与しましたが、/etc/security/capability.confまだsudoなしではできません）setcap
少なくとも必要なだけキャップが適用されていることを確認してください。
% /sbin/getcap ./program
./program cap_net_admin,cap_net_raw=eip
capsh --print私のユーザーが表示したbash実行結果
% /sbin/capsh --print
Current: cap_setpcap,cap_net_admin,cap_net_raw,cap_sys_ptrace,cap_setfcap=i
Bounding set =cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_resource,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read,cap_perfmon,cap_bpf,cap_checkpoint_restore
Ambient set =
Current IAB: cap_setpcap,cap_net_admin,cap_net_raw,cap_sys_ptrace,cap_setfcap
Securebits: 00/0x0/1'b0
secure-noroot: no (unlocked)
secure-no-suid-fixup: no (unlocked)
secure-keep-caps: no (unlocked)
secure-no-ambient-raise: no (unlocked)
uid=1001(johndoe) euid=1001(johndoe)
gid=1001(johndoe)
groups=27(sudo),1001(johndoe)
Guessed mode: UNCERTAIN (0)
これで問題なくユーザーとpingを実行できます。 Debian では、ping は機能を認識しているようです。つまり、バイナリには必須機能があります。
% /sbin/getcap `which ping`
/usr/bin/ping cap_net_raw=ep
そしてpingソースコードから（https://sources.debian.org/src/iputils/3%3A20210202-1/ping/ping.c/）ランタイムの機能が改善されていないことがわかりました。つまり、ファイル機能が期待どおりに機能するのに十分です。私の結論は、実行可能ファイルが適切な機能を持っている限り、私のプログラムはまったく同じように実行する必要があるということです。
しかし、それは本当ではないようです。プログラムファイルに必要な（私の知る限り）機能を設定しましたが、実行するとEPERM。
プロセスをデバッグし、ソケットの作成を中断し、プロセス機能を確認すると、プロセスに有効な必須機能がないことが表示されます。
% grep Cap /proc/`pidof program`/status
CapInh: 0000000080083100
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 000001ffffffffff
CapAmb: 0000000000000000
CapInhと を確認するCapBndと、capsh --decode=...ビットが期待どおりに（前のcapsh --print出力と一致）表示されます。ただし、許可されたセットと有効なセット（CapPrmおよびCapEffそれぞれ）は私が期待するものとは異なります（おそらく私の例外が完全に間違っている可能性があります）。許可されるセットはcap_net_rawと仮定しますcap_net_admin。
cap_net_rawこの状況を解決するために、ソケットを作成する前にプログラムで有効にしようとしました。
cap_value_t needed[] = { CAP_NET_RAW };
cap_t caps = cap_get_proc();
cap_set_flag(caps, CAP_EFFECTIVE, std::size(needed), needed, CAP_SET);
if (cap_set_proc(caps))
{
// handle failure
}
EPERMしかし、今「予想」されているように、これは悲惨に失敗します（）。また、最初のビットにビットを追加しようとしましたが、CAP_PERMITTED修正結果が再び現れました。cap_set_proc()EPERM
ここで私が何を見逃しているか、誤解していますか？私のプログラムへのrawソケットアクセスを有効にするには何が必要ですか？
Debian 11 には、他のシステムに比べて厳しいルールと制限がありますか？
注：利用可能なRaspberry Pi OS（Debian 10）システムを確認しましたが、ユーザーの設定が同じであることが報告されcapshました（設定はまったくありません）。 Afaik、システムは基本的に実行されるので、私の結論は、Raspberry Pi OS / Debian 10が機能的に基本的により許容的/許容可能なセキュリティモデルを持っているということです。piCurrentBoundingAmbient
これはネームスペースに関連していますか？ファイルの所有権/権限？