# getcap ./some_bin ./some_bin =ep
そのバイナリには、最初から許可された (p) 有効な (e) すべての機能があります。
機能のテキスト表現では、先頭の = all= に相当します .cap_to_text(3) から マンページ:
先頭演算子が = の場合 であり、機能のリストが提供されていない場合、アクション リストは all を参照すると想定されます 能力。たとえば、次の 3 つの句は互いに同等です (完全に空の機能セットを示します):all=; =;cap_chown,<every-other-capability>= .
このようなバイナリは、機能境界セットによってのみ制限され、好きなことを何でも実行できます。これには、典型的なデスクトップ システムではすべてが含まれます (そうでなければ、su のような setuid バイナリ)。 期待どおりに動作しません)。
これは、libpcap で使用されるテキスト表現の「落とし穴」にすぎないことに注意してください。 :security.capability 内 getcap のファイルの拡張属性 /file/path =ep を出力します 、意味のあるすべてのビットが効果的にオン; 空 security.capability 、 /file/path = (= 何も続かない) が代わりに出力されます。
誰かがまだそのすべてについて納得していない場合は、ここに小さな実験があります:
# cp /bin/ping /tmp/ping # will wipe setuid bits and extented attributes
# su user -c '/tmp/ping localhost'
ping: socket: Operation not permitted
# setcap =ep /tmp/ping
# su user -c '/tmp/ping localhost' # will work because of cap_net_raw
PING localhost(localhost (::1)) 56 data bytes
64 bytes from localhost (::1): icmp_seq=1 ttl=64 time=0.073 ms
^C
# setcap = /tmp/ping
# su user -c '/tmp/ping localhost'
ping: socket: Operation not permitted
能力ではありません。
有効なセットと許可されたセットを意味します。
これは、機能が許可されたセット (p) に入れられることを意味します。 )、許可されたすべての機能が有効なセット (e) にコピーされます。 ).
e レガシー プログラム (おそらく現時点ではほとんどのプログラム) に使用されます。つまり、プログラムは機能を認識していないため、許可された機能から有効な機能に自分自身でコピーすることはできません。
(@mosvy が指摘したように) 空のセットのように見えるものが存在する理由については、ライブラリの作成者はすべてをまったく混同していません (無限とゼロは最も混同されている数の 2 つです)。