rc.local question/problem (partly solved w/ setenforce=0)

[Paul Morgan]

On Jul 3, 2011 5:38 PM, "Paul Allen Newell" <pnewell at cs.cmu.edu> wrote:
>
> On 7/3/2011 12:53 AM, Cameron Simpson wrote:
> > On 02Jul2011 22:26, Paul Allen Newell<pnewell at cs.cmu.edu>  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

it really is bad form to run a script out of root's home directory. Perhaps
put it in /usr/sbin , restorecon, and leave selinux enforcing the whole
time.

-paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraproject.org/pipermail/users/attachments/20110703/0bf67f17/attachment.html