Description of problem: Multipathd Segfaults when SELinux is enabled in both permissive and enforcing modes. The problem does not occur when SELinux is disabled. Multipathing is enabled for two iSCSI LUNS to an EMC-Celerra disk array. During the initial boot of the system with SELinux enabled, multipathd segfaults during what I believe is when /sbin/multipath is called. I do not have a trace to support this but all signs point to this. In SELinux permissive mode, when /sbin/multipath is run prior to multipathd, multipathd starts up just fine. After flushing the device maps and restarting multipathd, it will segfault again. In SELinux enforcing mode, I have created policies all the way up to the segfault. The first one below, is the last policy created before the segfault occurs. Unfortunately, the multipath map is not created since multipathd doesn't have the proper rights. module myMultipathd 1.6; require { type tmp_t; type sbin_t; type bin_t; type lvm_metadata_t; type lvm_t; type ramfs_t; class file create; class dir { write search add_name mounton }; class filesystem { mount unmount }; } #============= lvm_t ============== allow lvm_t bin_t:dir mounton; allow lvm_t lvm_metadata_t:dir mounton; allow lvm_t ramfs_t:dir { write search add_name }; allow lvm_t ramfs_t:file create; allow lvm_t ramfs_t:filesystem { mount unmount }; allow lvm_t sbin_t:dir mounton; allow lvm_t tmp_t:dir mounton; The following policy allows multipathd to create the multipath maps but then segfaults right after. module myMultipathd 1.7; require { type tmp_t; type sbin_t; type bin_t; type lvm_metadata_t; type lvm_t; type ramfs_t; class file { write create execute }; class dir { write search add_name mounton }; class filesystem { mount unmount }; } #============= lvm_t ============== allow lvm_t bin_t:dir mounton; allow lvm_t lvm_metadata_t:dir mounton; allow lvm_t ramfs_t:dir { write search add_name }; allow lvm_t ramfs_t:file { write create execute }; allow lvm_t ramfs_t:filesystem { mount unmount }; allow lvm_t sbin_t:dir mounton; allow lvm_t tmp_t:dir mounton; The following is a diff between the two: [root@xen01 multipathd]# diff myMultipathd.te.6 myMultipathd.te.7 2c2 < module myMultipathd 1.6; --- > module myMultipathd 1.7; 11c11 < class file create; --- > class file { write create execute }; 20c20 < allow lvm_t ramfs_t:file create; --- > allow lvm_t ramfs_t:file { write create execute }; Version-Release number of selected component (if applicable): Linux xen01.teoco.corp 2.6.18-53.1.14.el5xen #1 SMP Wed Mar 5 12:08:17 EST 2008 x86_64 x86_64 x86_64 GNU/Linux device-mapper-multipath-0.4.7-12.el5_1.2 How reproducible: Always. Steps to Reproduce: 1. Setup iSCSI devices 2. service multipathd start Actual results: The error reported in dmesg: SELinux: initialized (dev ramfs, type ramfs), uses genfs_contexts multipathd[18583]: segfault at 000000001b393ff8 rip 000000313746bab0 rsp 000000001b394018 error 6 Expected results: Additional info: /etc/multipath.conf: blacklist { devnode "*" } blacklist_exceptions { devnode "sd[c-z]$" } defaults { user_friendly_names yes } multipaths { multipath { wwid 36006048c5902486960827f1ce78636e2 alias emc_celerra01 path_grouping_policy multibus failback immediate } }
I'm hitting the same problem, and I'd like to raise the severity of this bug to "high" from "low". If it's uncomfortable, please let me know.
This bugzilla has Keywords: Regression. Since no regressions are allowed between releases, it is also being marked as a blocker for this release. Please resolve ASAP.
Confirmed this bug is fixed in device-mapper-multipath-0.4.7-17.el5.
I fixed this bug the same way as 355961, by using fork() and unshare(CLONE_NEWNS) instead of clone()
NetApp: The planned release for this is 2008-04-22.
I believe this has been pushed to 29-Apr-08 due to scheduling.
I believe this should be released on May-6.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2008-0219.html