Unix/Linux FTP デーモンでは、chroot を使用せずにユーザーを「監禁」できる​​ものはありますか?

Unix/Linux FTP デーモンでは、chroot を使用せずにユーザーを「監禁」できる​​ものはありますか?

FTP アカウントを特定の目的(データ ファイルを共有するためのドロップ ポイントなど)で設定する場合、ユーザーに特定のディレクトリへのアクセス権のみを与え、より広いファイル システムを表示しないようにするのが賢明です。

特に *nix システムでは、すべてのユーザーが などの多くのシステム ファイルへの読み取りアクセス権を持っているのが/etc/passwd一般的です。FTP デーモンでは通常、ログイン時に を実行してこれらを非表示にできるchrootため、ユーザーは仮想の「監獄」にいることになります。

しかしchrootセキュリティ対策として設計されたものではない[サイトがダウンしているようなのでコピーをアーカイブする]、さらにはセキュリティ上の問題を引き起こす可能性もあります。このため、vsftpdこの機能を制限しましたつまり、chroot読み取り専用ディレクトリにしかアクセスできず、ユーザーは書き込み操作を実行するためにサブディレクトリに移動する必要があります。プロFTPDは問題を警告しますが、代替手段は提供されておらず、PureFTPD では を使用するためにもさまざまな特殊ファイルを作成する必要がありますchroot

FTP アクセスを OS のファイルシステム アクセスの概念にマップする根本的な理由はないように思えます。HTTP デーモンと同様に、FTP デーモンは一連の構成ルールに従ってすべての要求を「書き換える」ことができます。Apache Web ホストにパスを要求すると、ホストOS の現在のディレクトリではなく、ディレクトリ/で定義されているディレクトリにマップされます。DocumentRoot/

私の質問は、*nix FTP デーモンはこのような「書き換え」メカニズム (またはアクセスを制限する他の方法) を使用しているか、また使用していない場合は根本的な理由があるかということです。


注: 一部重複ありこの既存の質問ただし、回答ではchroot完全な代替案ではなく、使用するかどうかが主に議論されています。

答え1

翻訳元:

仕様では、「宛先」またはサーバー側が特定の種類のファイル システムを指す必要があるとは述べられていないと仮定します。あまり深く読まなくても、合理的な方法でユーザーを監禁し、それでも実行可能なデーモンを誰でも作成できると思います。

あるいは、selinux のようなものは、ftp デーモンを変更することなく、ftp ユーザーを特定のディレクトリに制限できる可能性があります。

関連情報