3

I have a perl script that I want to run as a perorate script for log rotate. When I force log rotate to run from the command line as root, it works. However, when run through cron, SELinux prevents operation.

I don't remember what the first error was, but I fixed that using audit2allow. The next day, I got a SELinux is preventing /usr/bin/perl read access on the script. Fixed that, now I'm getting SELinux is preventing /usr/bin/perl from open access on the script. I can't wait to see what I get tomorrow (since I can't just run the thing to test, given that it runs fine when I run it manually.)- probably something about writing to one of the output files.

Is there any way to short-circuit this iterative process and just say yes, perl can run this script, even when launched from log rotate?

ibrewster
  • 387
  • 1
  • 4
  • 16

1 Answers1

4

It's much easier if you put SELinux into permissive mode. 

setenforce 0

In this mode SELinux will log the errors but take no action. This way you can collect all the relevant messages in one go and take appropriate action.

You should take the necessary steps to ensure that you exercise all of the relevant actions your script performs too.

You could probably run your cron job more frequently to gather the messages too.

user9517
  • 115,471
  • 20
  • 215
  • 297
  • Well, THAT produced a slew of errors in the audit log. We'll see tomorrow if running audit2allow on them cleaned it up. – ibrewster Dec 22 '15 at 17:37
  • 1
    Did you remember to cut `setenforce` back on? – chicks Dec 22 '15 at 17:55
  • @chicks Not yet. I figured I'd leave it off for another day, and make sure the audit logs remain clear, now that the allow policies are in place. – ibrewster Dec 22 '15 at 18:19