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