On Fri, Feb 01, 2008 at 08:12:38 -0500, Allan Fields wrote: > So far fixing the SELinux rules doesn't seem to do the trick, even though > audit2allow returned some rules. As recommended in the manpage you can > then compile these rules to a new policy (in the case the existing policy > is not functioning properly). > > # cat /var/log/audit/audit.log | grep iscsi | audit2allow -m local > > local.te > # checkmodule -M -m -o local.mod local.te > # semodule_package -o local.pp -m local.mod > # semodule -i local.pp > > netstat -nlt|grep 3260 > << no results >> I'm not sure this resolves anything (unless you're running in Permissive mode in which case your problem is not selinux). For one thing I often can't fix selinux issues in one pass like that. E.g. opening up permission for a "getattr" may simply lead to failure of a subsequent "write". Also while your "grep iscsi" probably isolates the iscsid_t domain, IMO it's kind of flying blind. Even for a quick and dirty solution I think it's a good idea to take a look at the rules, including what hasn't been resolved after a first (or second or ...) pass. But I'm not saying you need to wade through the full audit2allow output from audit.log*. E.g. if you have X and the setroubleshoot-* packages installed, you might want to see what the gui client (sealert -b) says, in real time. Without X perhaps sealert -a would be useful. >> On Thu, Jan 31, 2008 at 16:53:14 -0500, Allan Fields wrote: >>> One thing to note is the iscsid requires SELinux rules to be enabled. But perhaps running temporarily in Permissive mode (setenforce 0) would help isolate the problem. Joe