root@macine:~# getcap ./some_bin
./some_bin =ep
「ep」の意味は?このバイナリの機能は何ですか?
_# getcap ./some_bin ./some_bin =ep
_
そのバイナリには、最初から許可(p)および有効(e)なすべての機能があります。
機能のテキスト表現では、先頭の_=
_は_all=
_と同等です。 cap_to_text(3)
マンページから:
先頭の演算子が_
=
_であり、機能のリストが提供されていない場合、action-listはall機能を参照すると見なされます。たとえば、次の3つの句は互いに同等です(完全に空の機能セットを示します)。_all=
_; _=
_; _cap_chown,<every-other-capability>=
_。
このようなバイナリは、通常のデスクトップシステムにすべてが含まれている機能境界セットによってのみ制限されて、何でもできます(そうしないと、su
のようなsetuidバイナリは期待どおりに機能しません)。
これは、libpcap
が_security.capability
_を出力するファイルの_/file/path =ep
_拡張属性内のgetcap
によって使用されるテキスト表現の「ごちゃごちゃ」にすぎないことに注意してください。すべての意味のあるビットは効果的にon; empty_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つです)。