3

セーフモードは5.3.0として非推奨になりました。私は実際にそれを必要としたことはなく、許可エラーなどのために過去に何度も問題があることに気づきました。

しかし、私は今、セーフモードがうまくいくと思うという要件があります。

モジュールを介して拡張可能なWebアプリケーションを構築しました。私は自分でシステムをホストし、システムのさまざまな部分にフックするモジュールを実装および作成することで、有料の顧客がソフトウェアを拡張できるようにすることを計画しています。

私の懸念は、そうすることによって、彼らがアップロードしたコードが、文字通り何年もかけて設計とテストに費やした基盤/フレームワークをスキャンしていないことを確認する方法がないことです。コードをプロプライエタリに保つことは私にとって非常に興味深いことです。

  1. モジュール分析ツールを作成して、サードパーティのモジュールで不正なメソッドが呼び出されていないことを確認します-簡単ではありません!!!

  2. php.iniレベルで有害な関数を無効にしますが、これにはfopen（）が含まれ、これは同類です。これは、フレームワークが独自のinclude（）操作などを呼び出せないことを意味します。

  3. 最後に、悲しいことに廃止されたセーフモードで、ユーザーモジュールが同じIDやグループなどを共有していないファイルを読み取れないようにします。

そのようなことへの推奨されるアプローチは何ですか？フレームワークのコンテキストで実行する前に、各モジュールを手動で確認または自動分析する必要がありますか？

4

3 に答える 3

1

safe_mode削除されているのは良いことです。それは誤った安心感であり、それを回避する方法はたくさんあります。

より良いアプローチは、suphpを使用してアプリケーションをjailされたユーザーとして実行することです。これは、オペレーティングシステムのセキュリティを使用してアプリケーションを保護します。を禁止する代わりにexec()、system()シェルにアクセスできないアカウントとしてphpコードを実行します。禁止する代わりに、fopen()そのユーザーが所有するすべてのものから書き込み権限を削除しますchmod 500 -R /。または、さらに一歩進んで、chroot内でアプリケーションを実行します。

于 2011-10-26T17:42:05.347 に答える