Apacheの実行権限について

質問

Apacheがユーザーディレクトリに、ディレクトリを作成したり画像を(アップロードして)作成したりする場合、以下のように設定していますができません。
httpd(子プロセス)の実行ユーザー／グループはそれぞれapacheです。
親プロセスはrootになっています。

以下のディレクトリは次のようになっています。
(ドキュメントルートはwordpressです)

/var/www/html/projectName/wordpress/wp-content/uploads
drwxrwxr-x(775) owner=yamada group=apache

このように、group(apache)に書き込み権限を与えているのですが、uploads以下にディレクトリやファイルの作成ができません。このディレクトリのownerをapacheにするとできるようになります。
apacheユーザーはapacheグループに属しているので、書き込み権限(w)をもってディレクトリの作成やファイルの作成ができるはず、という認識だったのですがなぜかできません。私の認識が間違っているのでしょうか。

回答No.4

anmochi · ベストアンサー

うーん、色々実験してみたけど今のあなたに有用な情報は得られなかった感じ。

環境：お名前.comのVPS（KVM）向けにちょいとカスタムされてるCentOS6.6（でもノーマルに比べてapacheの動作に影響はないはず）
前提：SELinux無効、ApacheとPHPとMySQLはCentOS標準リポジトリーのもの
条件１：httpdを動かしてるのはapache.apache
条件２：sshであれこれ操作する人はanmochi.users
条件３：$(wproot)とはwp-config.phpの親ディレクトリーの事
条件４：wp-config.phpには何も追記していない。

シナリオ１：
$(wproot)から全部所有者anmochi.users、ファイルは0644、ディレクトリーは0755
→メディアのアップロードできない（当然）

シナリオ２：
$(wproot)から全部所有者anmochi.users、ファイルは0644、ディレクトリーは0755で$(wproot)/wp-content/uploadsは0777
→アップロードできる。$(wproot)/wp-content/uploads/2015とか2015/04はapache.apacheの0777になった。

シナリオ３：
$(wproot)から全部所有者apache.apache、ファイルは0644、ディレクトリーは0755
→超普通

シナリオ４：
$(wproot)から全部所有者anmochi.users、ファイルは0644、ディレクトリーは0755で$(wproot)/wp-content/uploadsはanmochi.apacheで2775
→アップロードできる。$(wproot)/wp-content/uploads/2015とか2015/04はapache.apacheの2775になった。

シナリオ５：
$(wproot)から全部所有者anmochi.users、ファイルは0644、ディレクトリーは0755で$(wproot)/wp-content/uploadsを削除、$(wproot)/wp-contentをanmochi.apacheで2775
→アップロードできる。$(wproot)/wp-content/uploadsがWordPressにより作られてapache.apacheの2775になった。

うーん、後はもうあなたが実験あるのみだなぁ。
$(wproot)をあなたのユーザーとあなたのグループで0755、$(wproot)/wp-contentをあなたのユーザーでグループapacheの2775、($wproot)/wp-content/uploadsを完全にデリった状態で試してみて、「うまくいったかいかなかったか」ではなく「どうなったか」を補足していただけたらと思う。具体的に言えば、WordPressのメディアのアップロード画面で「書き込みできませんでした」と表示されるかされないか、($wproot)/wp-content/uploadsは作られたか作られなかったか、などだな。

お礼

回答ありがとうございました。

補足

詳細に本当にありがとうございます。
問題の件ですが、原因が判明しました。

まず、いくつか情報が不足していた点についてお詫び申し上げます。
anmochi様が最初に懸念していた通り、WordPressの実装による影響でした。
WordPressのバージョンは4.0.1です。

このアップロードは通常のメディアアップローダーではなく、WP_Filesystem APIというWordPressの実装により行っており、その中に原因がありました。これはWordPressの仕様でセキュリティを考慮されているためだと思われます。
WP_Filesystem APIは、WordPress上でファイルを操作するためのAPIですが、このAPIはファイルを操作するにあたり、システムが「安全」に操作を行える方法を direct, ssh2, ftpext, ftpsockets の順に検証し、いずれかでファイルを操作します。

今回、この検証の中でdirect（直接の書き込み）ができないと判定されていました。
この理由はおそらく、セキュリティ上の理由（仕様）で現在実行しているスクリプト（今回だとカスタム分類の編集ファイルなので/wordpress/wp-admin/edit-tags.php）のファイル所有者と、その内部で/wordpress/wp-content以下に生成される一時ファイル（判定を行うためにWordPressが生成する一時ファイル。apacheが生成するのでファイル所有者はapache）のファイル所有者との比較が行われ、これに相違がある場合はWP_Filesystem APIでは直接書き込めない仕様になっていました。

つまりアプリケーション及びWordPressの実装上、パーミッションだけでなく実行スクリプトとapacheの生成するファイルの所有者が一致している必要があったということです。実際に/wordpress/wp-admin/edit-tags.phpのファイルの所有者をapacheにすると書き込み・削除を行えるようになりました。

上記の仕様はあくまでWordPress 4.0.1での場合で、
所有者の比較は以下のようになっています。

if ( getmyuid() == @fileowner($temp_file_name) ) {
　$method = 'direct';
}

現行のWordPress 4.1.1では、
比較対象が__FILE__となっていてfile.phpと比較されるようになっています。

if ( function_exists('fileowner') ) {
　$wp_file_owner = @fileowner( __FILE__ );
　$temp_file_owner = @fileowner( $temp_file_name );
}
if ( $wp_file_owner !== false && $wp_file_owner === $temp_file_owner ) {
　// WordPress is creating files as the same owner as the WordPress files,
　// this means it's safe to modify & create new files via PHP.
　$method = 'direct';
　$GLOBALS['_wp_filesystem_direct_method'] = 'file_owner';
} else if ( $allow_relaxed_file_ownership ) {
　// The $context directory is writable, and $allow_relaxed_file_ownership is set, this means we can modify files
　// safely in this directory. This mode doesn't create new files, only alter existing ones.
　$method = 'direct';
　$GLOBALS['_wp_filesystem_direct_method'] = 'relaxed_ownership';
}

これらのWP_Filesystem APIがファイル操作にあたり行う検証は、/wordpress/wp-admin/includes/file.phpのget_filesystem_method()に実装があります。

ひとまずこの問題については、すべてのディレクトリとファイルの所有者をapache、グループをyamadaとすることで両者が操作を行えるようにして解決しました。
この設定が適切かについてはこれから勉強したいと思います。

長くなりましたが、最後までお付き合いいただき本当にありがとうございました。
最後に、以上のような結論についてanmochi様より何か一言ありましたらお願いします。
特になければ、その後ベストアンサーとして質問を締め切らせていただきたいと思います。
本当にありがとうございました。

回答No.3

anmochi

> 以下のとおり、SGIDも試しましたがうまくいきませんでした。
あれ、こっちでは普通にできたけど・・・・。こちらはCentOS 6.6でSELinuxは無効。apacheとPHPとMySQLはCentOS標準リポジトリーのものだ。WordPressは4.0.1をZIP解凍したものをWordPressの自動更新にて4.1.1にしたものだ。

wp-contentの中身というかuploadsを
drwxrwsr-x 7 anmochi apache 4.0K Apr 7 05:28 .
drwxr-xr-x 5 anmochi apache 4.0K Feb 24 17:19 ..
-rw-r--r-- 1 anmochi apache 28 Jan 9 2012 index.php
drwxrwsr-x 4 anmochi apache 4.0K Nov 22 08:33 languages
drwxrwsr-x 3 anmochi apache 4.0K Feb 1 02:08 plugins
drwxrwsr-x 6 anmochi apache 4.0K Feb 1 02:12 themes
drwxrwsr-x 2 anmochi apache 4.0K Apr 2 07:12 upgrade
drwxrwsr-x 3 anmochi apache 4.0K Apr 7 05:26 uploads
こんな風にオーナーanmochiのグループapacheにして2775というパーミッションにします。あれ、こんなのを公表したら駄目だったと言われて今あわてて実験してみたというのがバレちゃうじゃないか。ちなみに/からwp-contentまではオーナーapacheのディレクトリーとオーナーanmochiのディレクトリーが混在している。
そして管理画面のメディアから新規作成でここへファイルをドロップいう所に画像をドロップする。今このWordPressの設定では年月のディレクトリーを作ってファイルを入れる設定にしている。
そうするとwp-content/uploadsの中をls -lhすると
drwxrwsr-x 3 apache apache 4.0K Apr 7 05:26 2015
のようになってちゃんとディレクトリーが作られてファイルもアップロードされているようだ。

SELinuxとか、他の要因がこれを阻害していると思う。

補足

ご丁寧にテストまでしていただき、ありがとうございます。
お返事遅くなってすみません。

まずSELinuxですが、getenforceで動作を確認するとPermissiveになっていました。
この時点で、まだディレクトリ・ファイルの作成・削除ができないので、
/etc/selinux/configにSELINUX=disabledを設定し、サーバーを再起動した上でgetenforceでSELinuxが無効(Disabled)になっているのを確認し、再度画像のアップロードしましたがうまくいきませんでした。
SGIDについては、wordpressからuploadsディレクトリまでのディレクトリに2775を設定してあります。

wordpressからuploadsディレクトリまでのディレクトリの所有者をapacheにすることでできるようにはなるのですが・・・。
環境は以下のとおりです。

OS：CentOS 6.4
Apache： 2.2.15
PHP：5.3.3

度々すみませんが、他にお気づきの点あればよろしくお願い致します。

回答No.2

anmochi

WordPressを実行している環境はLinuxなのかな。こうしたらどうだろう。

/var/www/html/projectName/wordpress/wp-content/uploads
drwxrwxr-x(775) owner=yamada group=apache
↓
/var/www/html/projectName/wordpress/wp-content/uploads
drwxrwsr-x(2775) owner=yamada group=apache

簡単に解説しておくと、パーミッションの2000というのはSGIDと言い、これをディレクトリーに対して設定しておくと、その子供として作ったディレクトリーは自動的に親と同じグループになりさらにSGIDがつく、というものだ。
それが何を意味するかというのは是非とも自分で調べていただきたい。
ちなみに千番台のパーミッションには他に1000と4000がある。これもそれぞれ面白い意味を持っているので良ければ調べてみると良いだろう。

補足

回答ありがとうございます。
以下のとおり、SGIDも試しましたがうまくいきませんでした。
sudo chmod 2775 /var/www/html/projectName/wordpress/wp-content/uploads

んーなんでだろ
やはり、ドキュメントルートから当該ディレクトリまでの所有権がないとダメなのでしょうか

回答No.1

bigfatrat999

> 私の認識が間違っているのでしょうか。
Linuxの知識としては間違っていません。

なのでwordpressを使っていると言う所が気になります。
フォルダ毎の設定してもumask設定が有効であれば、
例えばumaskが755であればフォルダ側で何を設定しても022の部分は設定できないと言う事になります。

slowdancingさんのサーバ環境を見てみないとわからない事なので、
umask と言う単語に関連するコンフィグファイル等無いか調べてみてください。

補足

apacheのumaskは親プロセスのumask値を継承するようなので022になっていました。apacheのシステム設定ファイル(/etc/sysconfig/httpd)にumask 002を追記し、apacheを再起動することでumask値は変更できましたが、うまくいきませんでした。

また、WordPressはapacheのumask値を無視するという記事がありました。
http://www.teradas.net/archives/10547/

こちらの記事にあるとおり、以下をwp-config.phpのrequire_once(ABSPATH . 'wp-settings.php')の上に追記しましたが、こちらもうまくいきませんでした。
define('FS_CHMOD_DIR', ( 0775 & ~ umask() ));
define('FS_CHMOD_FILE', ( 0664 & ~ umask() ));

それと質問本文で1つ訂正ですが、wordpress/wp-content/uploadsの各ディレクトリ(ドキュメントルートからuploadsまで)のディレクトリ所有者(owner)をapacheにするとうまくいくのですが、uploadsディレクトリだけをapacheにしただけではうまくいきませんでした。

他に何か気づく点はありますでしょうか。
よろしくお願い致します。