Page 2 of 2

Re: SELinux Error for root cron jobs

Posted: 2016/03/08 23:17:49
by dunwell
the autorelabel thing came from
https://www.centos.org/docs/5/html/5.2/ ... label.html
I'm seeing that was for COS5 so maybe there is a difference.

There will be a slight pause as I have to get taxes efiled but will try to get on this tomorrow in more detail. Since any cron job running from the /var/spool/cron/root file seems to do this maybe the simplest is to just make a HelloWorld bash script and add it to the cron file to run every minute and then do your tests. More tomorrow.
Alan D.

Re: SELinux Error for root cron jobs

Posted: 2016/03/09 15:34:12
by dunwell
I did a quickie bit to test. First I just made a super simple .sh file

Code: Select all

> cat Hello.sh 
#!/bin/bash
echo "Hello" >> /root/log
Then I modified the /var/spool/cron/root file to be

Code: Select all

87 dunwellguitar3:/var/spool/cron 
> cat root
00,10,20,30,40,50       *       *       *       *       /usr/local/solar-web_monitor/cgi-bin/fronius_daily_logger.pl
00,10,20,30,40,50      15-20      *       *       *       /usr/local/solar-web_monitor/cgi-bin/fronius_totals_logger.pl
00      21      *       *       *       /usr/local/solar-web_monitor/cgi-bin/fronius_totals_writer.pl
05	5	*	*	*	/root/backup2usb.sh
*	*	*	*	*	/root/Hello.sh
and waited a few minutes and check the log file

Code: Select all

73 dunwellguitar3:/root 
> cat log
Hello
Hello
Hello
Hello
Hello
so it it firing. I then checked /var/log/cron to see it it was throwing the same error

Code: Select all

31 dunwellguitar3:/var/log 
> tail -20 cron
Mar  9 08:01:01 dunwellguitar3 run-parts(/etc/cron.hourly)[20793]: starting 0anacron
Mar  9 08:01:01 dunwellguitar3 run-parts(/etc/cron.hourly)[20803]: finished 0anacron
Mar  9 08:01:01 dunwellguitar3 run-parts(/etc/cron.hourly)[20793]: starting 0yum-hourly.cron
Mar  9 08:02:08 dunwellguitar3 run-parts(/etc/cron.hourly)[20998]: finished 0yum-hourly.cron
Mar  9 08:10:01 dunwellguitar3 crond[21240]: (root) NULL security context for user, but SELinux in permissive mode, continuing ()
Mar  9 08:10:01 dunwellguitar3 CROND[21244]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Mar  9 08:10:01 dunwellguitar3 CROND[21245]: (root) CMD (/usr/local/solar-web_monitor/cgi-bin/fronius_daily_logger.pl)
Mar  9 08:20:01 dunwellguitar3 crond[21904]: (root) NULL security context for user, but SELinux in permissive mode, continuing ()
Mar  9 08:20:01 dunwellguitar3 CROND[21908]: (root) CMD (/usr/local/solar-web_monitor/cgi-bin/fronius_daily_logger.pl)
Mar  9 08:20:01 dunwellguitar3 CROND[21909]: (root) CMD (/usr/lib64/sa/sa1 1 1)
Mar  9 08:21:01 dunwellguitar3 crond[1279]: (root-V5) ORPHAN (no passwd entry)
Mar  9 08:23:01 dunwellguitar3 crond[1279]: (root-V5) ORPHAN (no passwd entry)
Mar  9 08:23:01 dunwellguitar3 crond[1279]: (root) RELOAD (/var/spool/cron/root)
Mar  9 08:23:01 dunwellguitar3 CROND[22385]: (root) CMD (/root/Hello.sh)
Mar  9 08:24:01 dunwellguitar3 CROND[22697]: (root) CMD (/root/Hello.sh)
Mar  9 08:25:01 dunwellguitar3 CROND[22868]: (root) CMD (/root/Hello.sh)
Mar  9 08:26:01 dunwellguitar3 CROND[23032]: (root) CMD (/root/Hello.sh)
Mar  9 08:27:01 dunwellguitar3 CROND[23203]: (root) CMD (/root/Hello.sh)
Mar  9 08:28:01 dunwellguitar3 CROND[23364]: (root) CMD (/root/Hello.sh)
Mar  9 08:29:01 dunwellguitar3 CROND[23528]: (root) CMD (/root/Hello.sh)
and you can see that it is NOT throwing the error. So I sit corrected in that the files themselves, or something related to variables, seem to be of importance, not just the "cron-ness".

I will be away most of the day but will check again later this evening and try some of the other suggestions you offered.
Alan D.

Re: SELinux Error for root cron jobs

Posted: 2016/03/09 17:11:44
by aks
I don't think you should edit /var/spool/cron/root directly, you're better off using the crontab command, the interfaces may change one day - they haven't for quite a few years, but you never know (and that's why we have the crontab -e command).

Please do come back with results.

Re: SELinux Error for root cron jobs

Posted: 2016/03/10 21:38:27
by dunwell
I have been trying various things.

First, I used my current Hello.sh program and modified it as you had suggested for the backup job. It now looks like

Code: Select all

> cat Hello.sh 
#!/bin/bash
echo -n 'Started at: ' `date` >> /root/log
echo "Hello" >> /root/log
I then edited the /var/spool/cron/root job but heeding your caveat I used crontab -e to do so. I un-commented the line that runs the Hello.sh file every minute. I then got to thinking about how adding that line made that work w/o the error message but not the other lines. I remembered that the entire root file had been brought over whole-cloth from my CentOS5 server and placed here. I wondered if maybe each line had to be modified for crontab to pick up changes so I did the classic mistake and modified more than one thing at a time. I added and then removed a letter in each line. I then saved and exited. I could not figure out how to "mad face save" the file as you suggested
"then use the vi command :x to save the file and exit" :lol: :lol:
so I just used the :wq method. ;)

Anyway, it responded with

Code: Select all

crontab: installing new crontab
and I could see that there were Hellos in the log file and no error messages. This implies that either using crontab -e or the modification of individual lines corrected the problem, what ever it was, that was throwing the error messages. I let it run a bit and could see both the Hellos and the fronius_daily_logger.pl scripts were running w/o error messages.

To be through though I did as you suggested and added the crontab job directly with

Code: Select all

106 dunwellguitar3:/root 
> echo "* * * * * echo 'HELLO' >> /root/log2" > cronjob
107 dunwellguitar3:/root 
> cat cronjob | crontab
108 dunwellguitar3:/root 
> crontab -l
* * * * * echo 'HELLO' >> /root/log2
109 dunwellguitar3:/root 
> rm -f cronjob
I also did
touch /root/log2
chmod 755 /root/log2
At this point I could see the Hello stuff in the log2 file so I cleared both logs and let them run a while.
OOOOOOpppppps. It was a mistake to do as you suggested and enter the crontab job with cronjob | crontab. This trashed my original /var/spool/cron/root job and replaced it with just the one line for logging to log2 :o

Code: Select all

113 dunwellguitar3:/var/spool/cron 
> dir
total 12K
   0 drwx------.  2 root root   31 Mar 10 10:19 ./
4.0K drwxr-xr-x. 13 root root 4.0K Dec 20 14:57 ../
4.0K -rw-------.  1 root root   37 Mar 10 10:19 root
4.0K -rw-------.  1 root root  473 Dec 13 15:39 root-V5
114 dunwellguitar3:/var/spool/cron 
> cat root
* * * * * echo 'HELLO' >> /root/log2
Luckly I have a copy of the original file so I can modify it again. using crontab -e, to get it back to working for the original scripts. I will do that and report back as to whether it is still throwing error messages after the recovery.

Alan D.

[Solved]Re: SELinux Error for root cron jobs

Posted: 2016/03/10 23:32:09
by dunwell
OK, I'm going to call this fixed and do a quick summary here of the solution.

The initial problem was that I was seeing error messages in /var/log/cron and in my logwatch files of the form

Code: Select all

Mar  3 08:30:01 dunwellguitar3 crond[8463]: (root) NULL security context for user, but SELinux in permissive mode, continuing ()
Mar  3 08:30:01 dunwellguitar3 CROND[8468]: (root) CMD (/usr/local/solar-web_monitor/cgi-bin/fronius_daily_logger.pl)
This was as a result of the cron job /var/spool/cron/root running. There were four individual lines there running a bash shell script and various perl scripts and all of them threw the error when run.

The problem turned out to be related to the fact that the root cron file had been brought over whole-cloth from my CentOS5 server and just plopped in /var/spool/cron. So although they ran because of SEL being in permissive mode they threw the mysterious error message.

The Solution turned out to be to edit the root file but NOT directly with vi or nano but rather with the "crontab -e" command. This opens the root file and allow editing but also does an update of crontab on exit/save. Further, I forced all the lines in the root file to seem to have been changed by adding/deleting a letter in each line.
NOTE: This modification of each line may or may not have been necessary, I report it in case it is important but I suspect that the crontab -e type edit is the critical issue.
Once this change was done with crontab -e the error messages went away completely.

The SELinux labels now look like

Code: Select all

126 dunwellguitar3:/var/spool/cron 
> ls -laZ
drwx------. root root system_u:object_r:user_cron_spool_t:s0 ./
drwxr-xr-x. root root system_u:object_r:var_spool_t:s0 ../
-rw-------. root root unconfined_u:object_r:user_cron_spool_t:s0 root
WARNING:
Be aware that direct change of the crontab as root with commands of the form

Code: Select all

echo "* * * * * echo 'HELLO' >> /root/log" > cronjob
cat cronjob | crontab
crontab -l # you should see the cron job printed.
rm -f cronjob
will destroy the current /var/spool/cron/root file! Be sure to make a backup copy of the file if you choose to use this type of modification.

[Note:]
It may be that my current file tree structure for cron is wrong. I have it as /var/spool/cron/root. I have seen in some online documents that perhaps it should be /var/spool/cron/crontab/root and other usernames at that lower level. This may only be in some other nixes than CentOS though, not sure.

What is still NOT understood is exactly why it was throwing the message and why that particular non-informative and seemingly unrelated message.

I want to thank all the folks that chimed in here with help and in particular aks who's perseverance was admirable :!: :!: This forum is a standard to which other fora only wish to rise. Kudos to all.

Alan D.

Re: [Solved] SELinux Error for root cron jobs

Posted: 2016/03/11 18:15:32
by aks
First of all glad it works. Finally!
Second, /var/spool/cron/root vs /var/spool/cron/crontab/root this is distribution specific and further depends on the "root" of the distribution (BSD vs SysV and such things).
Third, the cron job file was probably mislabeled in some manner, writing back to it by the supported interfaces could have relabeled it (SELinux is very clever).
Well done, glad it works.