umask を改善する

[seasoftjapan]

何箇所か umask(0) が実装されている。これは以下の目的と理解している。

• ファイル群の管理を行うOSユーザーとは別のユーザー (典型的には apache や nobody) で PHP を実行している場合に、EC-CUBE が新たに作成したファイルを、管理者が容易に変更できるため。
• バッチ処理を WEB の PHP と別のユーザー (典型的にはファイル群の管理ユーザー) で実行した際に生成されたファイルを WEB から変更できるため。

しかし、suEXEC などで、同一ユーザーで PHP 実行している環境では、そういった考慮は通常不要。

また、過去に umask が反映されていないファイルが作成されるケースを見かけた記憶がある。(現バージョンの標準実装の範囲で生じ得るかは不確か。)

対応案

• ファイル所有ユーザーと PHP 実行ユーザーが同一の場合、umask を実行しない。
  • 基準とするファイルは、実行中のファイル自身 (FILE) で考えている。
    • 直接実行されたファイル ($_SERVER['SCRIPT_FILENAME'] 相当) だと、EC-CUBE が作成したファイルというケースも考えられ、不適当と考える。(例: html/user_data/*.php)
    • より適したファイルがあれば (直ぐに思いつかない)、そのファイル固定ということも考えられそう。
  • ディレクトリを SGID しているケースでは、ファイル所有ユーザーと PHP 実行ユーザーが相違しても、umask(0) は通常不要なはず。umask(0002) が期待されるケースが多そうだが、そもそもシステム構成として対応していそうなので、EC-CUBE 側では umask を制御しないのが良いかも。しかし、書き込み先のディレクトリのSGIDに依るはずなので、書き込み先に依って umask 値を変える必要があり、この対応ではカバーしきれない。(全ファィル同一条件なら、後述の設定でカバーできそう。)
• umask の実行タイミングを早める。
  • SC_Initial::requireInitialConfig() より後で間に合うならば、設定 (data/config/config.php) で umask の無効化や umask 値を強制できそう。

    define ('UMASK', 0022);
    define ('UMASK', false); // 制御しない
    

[nanasess]

不正アクセスによる改竄への安全性を考慮すると、Webサーバーの実行ユーザーと、EC-CUBEのファイルのオーナーは別の方が望ましいです。
利便性は低下しますが、常に umask(0022) とした方がよいと思われます

[seasoftjapan]

不正アクセスによる改竄への安全性を考慮すると、Webサーバーの実行ユーザーと、EC-CUBEのファイルのオーナーは別の方が望ましいです。

「望ましい」のは確かだと思います。

ただ、複数のアプリケーションが同居する環境では、各々の実行ユーザーを分けるトレードオフとして、ファイル所有者と実行ユーザーを同一とする運用は見かけます。

また、共用サーバーなど root 権限が与えられない環境では、(サーバー変更以外に) 回避できない事もあろうかと思います。

よって、どちらが望ましいかはあるにせよ、どちらも想定するのが良いとは考えています。

利便性は低下しますが、常に umask(0022) とした方がよいと思われます

PHP実行環境側でより厳しい値 (0027 など) を設定しているケースでは不必要に脆弱となる懸念もありますので、umask(umask() | 0022) の方がより良いように思います。

ただ、通常はPHP実行環境側で 0022 辺りが設定されていて、他の値を設定するのはそれなりの事由があるのでしょうから、EC-CUBE 側では一定の値で umask を行わず「umask を実行しない」で良いのではないかと考えています。

その上で、従来の umask(0) は単純に切り捨てて、「個別サイトでカスタマイズしてください」で良いのかといった辺りが気になります。

まず思い浮かぶのは、「追加したテンプレートを FTP で編集できない」「商品画像を FTP から削除できない」などの影響でしょうか。

[seasoftjapan]

以下で実装されたようですね。
http://svn.ec-cube.net/open_trac/changeset/17621
http://svn.ec-cube.net/open_trac/changeset/17622

「インストール時にパーミッションエラーになってしまう問題」というのが、若干引っかかります。
自分の脳内インタプリターで再現できない...

[nanasess]

@seasoftjapan

まず思い浮かぶのは、「追加したテンプレートを FTP で編集できない」「商品画像を FTP から削除できない」などの影響でしょうか。

ほとんどの共有レンタルサーバーでは、Webサーバーの実行ユーザーと FTP ユーザーは共通なので、最近はこういったトラブルは少なくなってきていますね

「インストール時にパーミッションエラーになってしまう問題」

当時はパッケージする際にパーミッションを設定していたと記憶しているので、そのあたりが関係しているのかもしれません