web-dev-qa-db-ja.com

suPHP:chroot機能の適切な使用

私は最近suPHPを使い始めましたが、構成とさまざまなコンパイルオプションのデバッグに驚くほどの時間を費やして、実際に機能するものを取得しています。メーリングリストを通じて開発チームに連絡しようとしましたが、明らかに幽霊でできています...

chrootパラメータを使用しようとしていますが、500の内部エラーが発生し、解決できません。

DocumentRoot定義にDBDMySQLを使用しています。

<VirtualHost *:80>
    ServerName *

    DBDriver mysql
    DBDParams <params>
    DBDocRoot "SELECT document_root FROM domains WHERE name=%s" HOSTNAME

    suPHP_Engine on
    AddType application/x-httpd-php .php .php3 .php4 .php5 .phtml
    suPHP_AddHandler application/x-httpd-php
</VirtualHost>

VirtualHostがDocumentRootを設定すると、suPHPは追加のchrootを適用することになっています。以下の私の/etc/suphp.confの関連セクションを参照してください。

docroot=${HOME}
chroot=${HOME}

allow_file_group_writeable=false
allow_file_others_writeable=false
allow_directory_group_writeable=false
allow_directory_others_writeable=false
check_vhost_docroot=false

chrootパラメータはおそらくこれ以上単純なものではありませんが、suPHPは次のよ​​うに吐き出します。

Caused by SystemException in API_Linux.cpp:465: chdir() failed: No such file or directory

... PHPスクリプト。suphpログに情報が含まれていない場合、この行はApacheエラーログから取得されます。

anyone地球上で実際にこの恐ろしいchroot機能を設定する方法はありますか?私はリストから数え切れないほどのフォーラムやメールを読んできましたが、まだ誰も適切な答えを出していません(この機能に信じられないほどの回数パッチが適用されているにもかかわらず)。または、より満足のいく結果が得られることを期待して、suExecに切り替える必要があります...?

1
John WH Smith

あなたの問題は、chrootがどのように機能するかを理解していないという事実によって引き起こされます。/home/userにchrootすると、それが新しいルートになり、パスはそれに「相対的」になります。したがって、ファイルが/ home/user/public_htmlにあり、/ home/userにchrootしたい場合、chdirは実際には/ public_htmlであり、fastcgiドキュメントのルートは同じ(/ public_html)になります。

プロセスを起動する方法のより遠いポイントでsuPHPがchrootを実行することは技術的に不可能です。

0