Description of problem: Unexpected SELinux error message during iSCSI target exception testing: " Aug 29 11:27:55 srv01 setroubleshoot: SELinux is preventing iscsid (iscsid_t) "read" access to meminfo (proc_t). For complete SELinux messages. run sealert -l 43cf1922-eedd-4526-ac77-cc41a920f67b " Version-Release number of selected component (if applicable): selinux-policy-2.4.6-30.el5 selinux-policy-targeted-2.4.6.30.el5 How reproducible: Often Steps to Reproduce: Started with iSCSI system with 2 Bulldog controllers, and configured with two iSCSI ssid connection "sessions: 1) Created 4 RAID0 disk groups 2) Assigned them to qty-2 iSidewinder controllers (Bulldog). Assigned 2 groups each to controller 0 and to controller 1. 3) Ran heavy IO (using command "iogen -n10 -b512k -d sdb" for instance to run exerciser on virtual disk SDB. Ran heavy IO using same command on all 4 virtual disks. 4)Used Rossini to take controller 1 offline, then pulled controller 1 out of slot in enclosure 5)Verified that I/O resumed on fail-over path and controller 1 marked offline. 6)Replaced controller into system put controller 1 back online via Rossini, looked at recovery Guru, and "virtual disk not on preferred path" error persisted even though both controllers were in system. 7) Looked at the "view/end iscsi sessions" entry under the iSCSI tab. Though originally there were two instances of connections (i.e. two unique SSIDs for connection, temporarily only one was evident. Eventually, the second connection showed back up in this view. 8) Showed to Rob, who looked for instances of missing connection in /var/log/messages file (attached "messages" file)...which he noted evidence of missing connection. Actual results: Expected results: Additional info: Is iscsid killed when you see the selinux errors and does the session evetually come back? I don't know whether iSCSId was killed when I had the selinux errors (unfortunately didn't note the daemons at the time, and don't have this error on the system anymore)...sorry I can't answer this now, I don't know. The session just seemed to come back on its own after awhile after disappearing Could you also just tell me how you started the iscsi service? I wrote a script to find the targets to start the issi service, but at that time, I was manually going through and finding thepotential targets by first doing: iscisadm --mode discovery --type sendtargets --portal 192.168.100.10 (which generates a list of potential targets) then do iscsiadm --mode node --targetname<target> --portal 192.168.103.10 --login iscsiadm --mode node --targetname<target> --portal 192.168.103.11--login iscsiadm --mode node --targetname<target> --portal 192.168.104.12--login iscsiadm --mode node --targetname<target> --portal 192.168.104.13--login where <target> is list of potential targets from discovery command above
Created attachment 202551 [details] SELinux conf file
Please attach /var/log/audit/audit.log
Also could you put the machine in permissive mode and grab all of the iscsi avc's when it starts.
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release.
Without further input there is nothing I can do to fix this problem.