回答:
私は完全に理解しているとは思いません:
「クライアントユーザーはroot権限を持っているため、NFSv4のようにマシンの信頼に依存したくありません。」
クライアントユーザーがクライアントのroot権限を持ち、ホストにrootを持たせたくない場合は、「no_root_squash」オプションを使用しないでください。また、サーバーからクライアントへのリスクを軽減するために、setuidを無効にするなどのこともできます。
NFSv4でkerberosを使用するオプションもあります。このリンクを参照してください。
つまり、言い換えると、NFSv4は、少しでも必要なセキュリティを提供できるかもしれません...(スケーラブルですか?)..どこでもsshfsを使用しています。それでもあなたが望むものではないかもしれませんが、私はすぐにそれをあきらめません。
Kerberosでは、kdcサーバーのみが認証トークンを付与します。クライアントマシン自体はホストとしてのみ認証でき(つまり、一致するnfs / client-hostname @ REALMプリンシパルにキータブを与える場合)、それはそれにnfsサーバーと通信する権利を与えるだけです。認証できるのはユーザーであり、nfsサーバーはユーザーに自分のファイルへのアクセスを許可するだけです。sec = krb5pを使用すると、サーバーはスヌーピングと変更も防止します。
rootであることは、ユーザーに不適切な特権を与えることにはなりません。彼らがより多くのファイルにアクセスする唯一の方法は、お互いのマシンをハッキングし、nfsサーバーまたはkdcをハッキングすることです。Kerberosを使用するNFSv4は、セキュリティ要件によく適合します。
セキュリティモデルの詳細は次のとおりです。
デプロイメントを見ている場合は、debian / ubuntu中心のチュートリアルをいくつか示します。LDAPを使用しない簡単なセットアップを選択しました。これらのディストリビューションにはdebconfベースの構成があり、そこにいくらかの方法があります。
私の追加:des-cbc-crc enctypeを指定する必要はありませんが、通信プロトコルがストリーム暗号化にdes-cbc-crcを使用できるように、krb5.confでallow_weak_cryptoを指定する必要があります。これは2.6.35カーネルでは不要になります。
アプライアンスのようなものを見ている場合は、FreeIPAがあります。