rootユーザーは機能チェックをバイパスしますか？
rootユーザーはカーネルの機能チェックをバイパスしますか、それともrootユーザーはLinux2.2以降の機能チェックの対象になりますか？
特定の機能がその機能セットから削除された場合、アプリケーションはrootユーザーのアクセスをチェックして拒否できますか？
デフォルトでは、rootユーザーは完全な機能セットを持っています。
私が尋ねている理由は、man capabilitiesを除いて次のとおりです。
Privileged processes bypass all kernel permission checks
ただし、Linux2.2のリリース後もこのルールが適用されるかどうかについては何も述べられていません。
Extra：Dockerは、新しいコンテナーの起動中にrootユーザーから特定の機能を削除します。ただし、Dockerはデフォルトでユーザー名前空間を使用しないので、rootユーザーの機能はどのように復元されますか？
man capabilities：
従来のUNIX実装では、権限チェックを実行するために、特権プロセス（有効なユーザーIDが0、スーパーユーザーまたはルートと呼ばれる）と非特権プロセス（有効なUIDがゼロ以外）の2つのカテゴリのプロセスを区別します。特権プロセスはすべてのカーネルパーミッションチェックをバイパスしますが、非特権プロセスはプロセスの資格情報（通常：有効なUID、有効なGID、および補足グループリスト）に基づいて完全なパーミッションチェックの対象となります。
カーネル2.2以降、Linuxは、従来スーパーユーザーに関連付けられていた特権を、機能と呼ばれる個別の単位に分割します。これらの単位は、個別に有効または無効にできます。機能はスレッドごとの属性です。
rootユーザーは、その一連の機能に制約を受ける可能性があります。 capabilities(7)から：
実効ユーザーIDがゼロ以外から0に変更された場合、許可されたセットが実効セットにコピーされます。
これは、機能モデルでは、rootユーザーになると、従来のモデルとは異なり、すべての権限が付与されるわけではないことを意味します。機能モデルはLinux2.2以降で使用されます。
プロセスの機能の境界セットは、その親から継承されます。 Dockerがコンテナーを開始するスレッドの境界セットから機能を削除すると、それらの機能はコンテナーに対して削除され、rootユーザーかどうかに関係なく、そのコンテナーのすべてのプロセスに影響します。残っている機能は、コンテナ内のrootユーザーがユーザーID 0を取得したときに継承されます（clone(2)によって作成された特定の名前空間内）。
これらの機能の範囲は、さまざまなサブシステムの新しい名前空間を作成するclone(2)に渡されるパラメーターによって制限されます。 cgroups;およびAppArmorやSELinuxなどの追加のセキュリティサブシステム。
最初の段落全体を「古い方法」の説明として読み、2番目の段落を現在の状況（過去21年ほど）の説明として読むことになっていると思います。
パーミッションチェックを実行するために、従来のUNIX実装プロセスの2つのカテゴリを区別します。[...]特権プロセスはすべてのカーネルパーミッションチェックをバイパスします
カーネル2.2以降、Linuxは、従来スーパーユーザーに関連付けられていた特権を、機能と呼ばれる個別の単位に分割します。これらの単位は、個別に有効または無効にできます。機能はスレッドごとの属性です。