結論から先に書くと、CentOS 6系ではApacheのsuEXECに関するログは/var/log/httpd/suexec.logに出力されていたが、CentOS 7ではsyslog経由で/var/log/secureへ出力されるように変更されていた。
このログはjournalctlでも確認出来る。journalctlの場合は下記の様なコマンドでtail -fと同様な閲覧方法が可能だ。
# journalctl -f
設定の確認
suexec -Vコマンドでコンパイルオプションを確認出来る。ログ関連の部分をみるとCentOS 6の場合はAP_LOG_EXEC="/var/log/httpd/suexec.log"でファイルが指定されているが、CentOS 7ではAP_LOG_SYSLOGでsyslogがログの出力先として指定されている。
CentOS 6の場合
suexec -V -D AP_DOC_ROOT="/var/www" -D AP_GID_MIN=100 -D AP_HTTPD_USER="apache" -D AP_LOG_EXEC="/var/log/httpd/suexec.log" -D AP_SAFE_PATH="/usr/local/bin:/usr/bin:/bin" -D AP_UID_MIN=500 -D AP_USERDIR_SUFFIX="public_html"
CentOS 7の場合
# suexec -V -D AP_DOC_ROOT="/var/www" -D AP_GID_MIN=100 -D AP_HTTPD_USER="apache" -D AP_LOG_SYSLOG -D AP_SAFE_PATH="/usr/local/bin:/usr/bin:/bin" -D AP_UID_MIN=500 -D AP_USERDIR_SUFFIX="public_html"
Red Hat Enterprise Linux 7のドキュメントにもsyslog経由になったことが記載されているのを見つけたことでようやく分かった。
https://linux.web.cern.ch/linux/centos7/docs/rhel/Red_Hat_Enterprise_Linux-7-Migration_Planning_Guide-en-US.pdf
Changes to suexec
The suexec binary no longer has its user identifier set to root at install time. Instead, a more
restrictive set of permissions is applied using file system capability bits. This improves the
security of the httpd service. Additionally, suexec now sends log messages to syslog instead of
using the /var/log/httpd/suexec.log file. The messages sent to syslog appear in
/var/log/secure by default.
今回はログの出力先の変更ができるかどうかについては確認していない。
経緯
Apacheのログは/var/log/httpd/以下に必ずあるはずだという思い込みがあったので、suEXECのエラーが出力されていることに気づかなくてCGIが動作しない原因を特定するのに時間が掛かってしまった。
なんでこんなことを調べたかというと、サーバをCentOS 6から7へ移行していて、RubyのCGIの動作確認をしようと思ったら動かなかったからだ。(実際にはRubyのCGIを運用しているわけではないんだけど、、、)
エラーログには次のようなログが残っているだけ。
End of script output before headers: ruby.cgi
CGIがそもそも実行できてないようだ。最初はRubyがrbenv環境であることが原因かと思っていた。
ところが、動作確認でいつも使っている次のような簡単なPerlのCGIでも同様なエラーで動作しなかったので、Rubyとかいう以前にCGI自体が実行できていないことが分かった。
$ vi perl.cgi ------------------- #!/usr/bin/env perl print "Content-Type: text/html\n\n"; print "hello"; ------------------- $ chmod 755 perl.cgi
さらに調べると、suEXECを設定している環境の一部のディレクトリでだけ動作しなかったので、suEXECが原因であることは特定できた。
ところがsuEXECのログがどこに出力されているのかわからなくて、どの設定が悪いのかすぐには気づかなかった。
/var/log/secureに出力されていることがようやく分かってからは原因はすぐに特定できた。
CGIが動作しないのは実行ファイルを設置しているディレクトリのが他ユーザでも書き込みできるパーミッションであることが原因だった。
Sep 14 18:45:07 hostname suexec[22806]: uid: (1000/username) gid: (1000/username) cmd: perl.cgi Sep 14 18:45:07 hostname suexec[22806]: directory is writable by others: (/var/www/username/example.com/htdocs)
lsで確認すると確かに775のパーミッションでグループに書き込み権限がある。
なんでこんなパーミッションにしてあったのか自分でもよくわからない・・・
$ ll -d /var/www/username/example.com/htdocs drwxrwxr-x 31 username 4096 9月 14 18:44 /var/www/username/example.com/htdocs/
パーミッションを755にすることで無事CGIが動作するようになった。
$ chmod 755 /var/www/username/example.com/htdocs/
ちなみに、設置したディレクトリのパーミッションだけではなく実行ファイル自体のパーミッションによってもCGIが実行できなくなる。
$ chmod 757 perl.cgi
実行ファイルを757のパーミッションで実行してみると次の様なエラーが出力される。
Sep 14 18:46:55 hostname suexec[23043]: uid: (1000/username) gid: (1000/username) cmd: perl.cgi Sep 14 18:46:55 hostname suexec[23043]: file is writable by others: (/var/www/username/example.com/htdocs/perl.cgi)
どのような条件でCGIの実行に失敗するかはApacheのドキュメントで確認できる。
suEXEC サポート – Apache HTTP サーバ バージョン 2.4
今回は次の条件の時にCGIが動作しないということを確認している。
14. ディレクトリを他のユーザが書き込めるようになって いないか?
ディレクトリを他ユーザに開放しないようにします。 所有ユーザだけがこのディレクトリの内容を改変できるようにします。…略
16. 対象となる CGI/SSI プログラムファイルが他アカウントから 書き込めるようになっていないか?
所有者以外には CGI/SSI プログラムを変更する権限は与えられません。
教訓
CentOS 7なんだからjournalctl使えよってことだろうか・・・
関連記事
- None Found