systemdユニットファイルを使用して、非ルートとしてウェブサーバーを起動しています。
listen tcp :80: bind: permission denied
すでに実行したにもかかわらず
setcap cap_net_bind_service=+ep
実行可能ファイル。
私が見つけたインターネット上のユニットファイルの例で
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_BIND_SERVICE
ユニットファイルで使用されます。だから私はそれを試しました、そして突然アプリケーションはポート80をバインドすることができます。
それは何を教えてくれますか? setcap
は古い/非推奨/無視されますか? systemdによってのみ、またはLinuxによって一般に?
一般に、systemdはsetcap
で管理されるファイル機能では機能せず、代わりにサービスユニットの一部として構成する必要があると言って間違いありません。
したがって、setcap
が完全に非推奨になっているわけではありません...(systemdによって起動されたサービス以外にも有効な使用法があるかもしれません。)しかし、少なくともsystemdサービスでは機能しません。
実際、ファイル機能(setcap
によって設定)は最初から常に疑わしく、疑わしいものでした...それらは、「継承可能な」機能の使用を必要とします。 「アンビエント」機能のカーネル機能は、これらの問題の多くを解決するために導入され、新しいシステムが採用しているものです(systemdはここに含まれています。ご覧のとおり、AmbientCapabilities=
を使用してサービスを管理し、低いポートにバインドできるようにします。
機能のトピックはかなり複雑です...この問題をおそらくより穏やかに紹介するには、LWNで "Inheriting capabilities" を確認することをお勧めします。完全な詳細(機能セットの代数表記を含む)については、 capabilities(7) のマニュアルページを参照してください。