On 7/3/2011 12:53 AM, Cameron Simpson wrote: > On 02Jul2011 22:26, Paul Allen Newell<pnewell@xxxxxxxxxx> wrote: > | On 7/2/2011 10:06 PM, Joe Zeff wrote: > |> On 07/02/2011 09:45 PM, Cameron Simpson wrote: > |>> That should be the case. (Of course, SELinux can break anything - if you > > > You can put it into non-enforcing mode on the fly with the command: > > setenforce 0 > > Run "setenforce 1" to turn it back on. > That seemed to do it ... wrapping the clamscan in setenforce=0 / setenforce=1 produced scans of all files and no errors. Many thanks for the advice on how to do. Of course, your comment in other email about "if you can establish that disabling selinux makes it work", I sure got alot of barking from selinux and guess I need to learn all about rules for it. Total of 355 errors regarding "read", "getattr", "search", "open", and "write". It appears that it is related to files/binaries/whatever in /bin, /sbin, and ~root (maybe /tmp?). I need to do some further debugging to confirm this (and to reduce the testing to something manageable) The suggestions the pop-up gives me are for "allow this access for now" as opposed to something more permanent. Before I go starting to learn about selinux rules, I wanted to check whether my sense that "if I do a setenforce=0 then I would expect selinux to be disabled until setenforce=1; hence, why does it need rules when disabled" is a proper way to look at it. And, yes, my security stance is such that I don't mind a temporary disable while clamscan is running, I would rather not permanently disable selinux. Thanks in advance, Paul -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
