Noritaka Sekiyama
moomi****@gmail*****
2014年 4月 30日 (水) 11:37:50 JST
Fork松島さん
せきやまです。素早いお返事をありがとうございます。
それを踏まえてまとめますと、私の直面した問題はSELinuxがenforcingだったことが原因であり、
permissiveまたはdisabledにすると解決するということになるかと思います。
また、ネットワークアドレスはご指摘の通り関係ございませんでした。
> policycoreutils-pythonパッケージを導入するとaudit2allowが利用可能になりますので、
> audit2allow -aでcorosync_tでどの操作が拒否されたのかを観察することができるとおもいます。
これを使うとわかりやすいですね。勉強になります。
> # CentOS6.4をお使いとのことですが、もしかしたらselinux-policyパッケージ(selinux-policy-targeted)の
> # バージョンかもしれません。(自信ないですが)
CentOS 6.4ではなくRHEL 6.4 なのですが、EC2のRHEL 6.4ではaudit2allowはデフォルトで使えるようでした。
# audit2allow -a
#============= corosync_t ==============
#!!!! The source type 'corosync_t' can write to a 'dir' of the following types:
# var_log_t, corosync_tmpfs_t, rgmanager_var_lib_t, rgmanager_var_run_t, wdmd_tmpfs_t, corosync_var_lib_t, corosync_var_run_t, cluster_tmpfs, corosync_var_log_t, cluster_var_lib_t, tmp_t, tmpfs_t, qpidd_tmpfs_t, initrc_state_t, corosync_tmp_t, rgmanager_tmpfs_t, var_lib_t, var_run_t, root_t
allow corosync_t pacemaker_var_lib_t:dir { write search read remove_name open getattr add_name };
#!!!! The source type 'corosync_t' can write to a 'file' of the following types:
# corosync_tmpfs_t, rgmanager_var_lib_t, rgmanager_var_run_t, wdmd_tmpfs_t, corosync_var_lib_t, corosync_var_run_t, cluster_tmpfs, corosync_var_log_t, cluster_var_lib_t, tmpfs_t, qpidd_tmpfs_t, initrc_state_t, corosync_tmp_t, rgmanager_tmpfs_t, var_lib_t, root_t
allow corosync_t pacemaker_var_lib_t:file { rename setattr read create write getattr link unlink open };
#!!!! The source type 'corosync_t' can write to a 'dir' of the following types:
# corosync_tmpfs_t, rgmanager_var_lib_t, rgmanager_var_run_t, corosync_var_lib_t, corosync_var_run_t, corosync_tmp_t
allow corosync_t pacemaker_var_run_t:dir { write remove_name search add_name setattr };
allow corosync_t pacemaker_var_run_t:sock_file { write create unlink setattr };
allow corosync_t rgmanager_var_lib_t:file { execute execute_no_trans };
allow corosync_t self:capability kill;
いろいろと教えていただいて、ありがとうございました。
--
Noritaka Sekiyama
Twitter: @moomindani
Blog: mooapp http://moomindani.wordpress.com (http://moomindani.wordpress.com/)
日付：2014年4月30日水曜日、時刻：11:30、差出人：Takehiro Matsushima：
> せきやま さん
>
> > こちらでは当初enforcingでうまく動作しなかったのをdisabledに変えて解決しました。
> > permissiveでは試してなかったので今試してみましたが、問題なく動作しました。
> > permissive or disabledならOKでenforcingだとNGのようです。
>
>
>
> SELinuxをPermissiveにしておくと実際にアクセス制御を行わず、ログだけを残すようになります。
> policycoreutils-pythonパッケージを導入するとaudit2allowが利用可能になりますので、
> audit2allow -aでcorosync_tでどの操作が拒否されたのかを観察することができるとおもいます。
> (SELinuxは詳しくないので...申し訳ございません)
>
> # CentOS6.4をお使いとのことですが、もしかしたらselinux-policyパッケージ(selinux-policy-targeted)の
> # バージョンかもしれません。(自信ないですが)
>
>
> > > iptablesで224.0.0.0/4のUDP IN/OUTを叩き落としてみましたが変化ありませんでした。
> > マルチキャストは使ってないつもりなのですが、
> > このアドレス（マルチキャストアドレス）でフィルタリングするということは、
> > どのような動作が想定されることになるでしょうか。
>
>
>
> 申し訳ございません、言葉足らずでした。
> 仰るとおりユニキャストを使用していますのでマルチキャストは出ていないはずですが
> EC2がマルチキャストを通さないとのことでしたので、「実はマルチキャストが出ているんじゃないか」
> と手元の環境を疑っての一手でした。
> マルチキャストを捕まえてログに吐くようにしても全然書かれなかったので、マルチキャストは間違いなく
> 使われていませんでした。
> お騒がせ致しました。
>
> --
> Regards,
> Takehiro Matsushima
> _______________________________________________
> Linux-ha-japan mailing list
> Linux****@lists***** (mailto:Linux****@lists*****)
> http://lists.sourceforge.jp/mailman/listinfo/linux-ha-japan