Something that's niggled me for a while are the empty Email messages generated by Anacron.
This is on FC4 / selinux-policy-strict-1.27.1-2.22
When the machine is left powered overnight, the normal /etc/cron.daily processes - including logwatch and logrotate - run perfectly happily and generate appropriate Emails.
By default, logrotate doesn't result in an Email, but for reasons unrelated to SELinux I have it set to run in debug mode, so my instance does. The Email from logrotate is effectively 'sent' by /etc/cron.daily as it wrappers all the output from its child jobs.
In contrast, logwatch sends its own Email independent of Cron's sendmail child process.
When the machine is depowered overnight and repowered in the morning, Anacron proceeds to run the various /etc/cron.daily scripts. With SELinux enforcing, logwatch runs normally, and generates its normal Email log summary.
However, logrotate's output is never seen, even though it can be seen from the various timestamps and filenames that logrotate has correctly run and suitably rotated all the logs.
The overall cron.daily Job launched by Anacron results in an empty Email, with no body and more particularly no Subject. The mail From address is set to "Anacron root@hostname".
Burrowing around the Anacron source it is apparent that under normal circumstances it would give the Email a subject of
"Anacron job cron.daily"
Given the behaviour I see, I think the problem is somehow related to the /etc/cron.daily/* processes not having rights to write to the file descriptor which is the input to Cron's overall sendmail process.
I've had a look through the SELinux policy to see if I can spot the difference between the permissions of Jobs launched by Cron and Anacron, and I'm afraid I can't see where the problem lies; since jobs launched by either method appear to run as system_crond_t, the difference in behaviour eludes me.
Can anyone else offer any insight into the problem?
Thanks,
Ted Rule wrote:
Something that's niggled me for a while are the empty Email messages generated by Anacron.
This is on FC4 / selinux-policy-strict-1.27.1-2.22
When the machine is left powered overnight, the normal /etc/cron.daily processes - including logwatch and logrotate - run perfectly happily and generate appropriate Emails.
By default, logrotate doesn't result in an Email, but for reasons unrelated to SELinux I have it set to run in debug mode, so my instance does. The Email from logrotate is effectively 'sent' by /etc/cron.daily as it wrappers all the output from its child jobs.
In contrast, logwatch sends its own Email independent of Cron's sendmail child process.
When the machine is depowered overnight and repowered in the morning, Anacron proceeds to run the various /etc/cron.daily scripts. With SELinux enforcing, logwatch runs normally, and generates its normal Email log summary.
However, logrotate's output is never seen, even though it can be seen from the various timestamps and filenames that logrotate has correctly run and suitably rotated all the logs.
The overall cron.daily Job launched by Anacron results in an empty Email, with no body and more particularly no Subject. The mail From address is set to "Anacron root@hostname".
Burrowing around the Anacron source it is apparent that under normal circumstances it would give the Email a subject of
"Anacron job cron.daily"
Given the behaviour I see, I think the problem is somehow related to the /etc/cron.daily/* processes not having rights to write to the file descriptor which is the input to Cron's overall sendmail process.
I've had a look through the SELinux policy to see if I can spot the difference between the permissions of Jobs launched by Cron and Anacron, and I'm afraid I can't see where the problem lies; since jobs launched by either method appear to run as system_crond_t, the difference in behaviour eludes me.
Can anyone else offer any insight into the problem?
Thanks,
Is this on FC5? If yes, are you seeing any AVC messages? If not could you attempt to enable audit
semodule -b /usr/share/selinux/targeted/enableaudit.pp
Create the error.
Grab the AVC Messages
semodule -b /usr/share/selinux/targeted/base.pp
to turn off auditing again.
Of course verifying this works with setenforce 0 would also help to make sure it is SELinux causing the problem.
The host is FC4 rather than FC5testN
In order to avoid having to run in permissive overnight or completely reload the policy at the moment, I've run the following test:
Create new directory /etc/anacron.daily and a corresponding entry in /etc/anacrontab. Create /etc/anacron.daily/0anacron and a test job /etc/anacron.daily/mailcheck. ( See below )
Run in enforcing by restarting anacron service with
sudo service anacron start
Wait 5 mins for Job to run, and note that the resultant Email is empty-bodied as with /etc/cron.daily
Check anacron stopped.
Delete the timestamp file /var/spool/anacron/anacron.daily
Goto permissive with
sudo setenforce 0
Wait 5 mins for Job to run, and note that the resultant Email is properly formed with Subject and body as expected.
Go back to enforcing.
This all seems to confirm to me that SELinux policy is somehow blanking the body and subject. The only denial messages I see during in permissive state are these:
Mar 15 15:12:53 topaz sudo: ejtr : TTY=pts/1 ; PWD=/home/ejtr ; USER=root ; COMMAND=/sbin/service anacron start Mar 15 15:12:54 topaz kernel: audit(1142435574.018:6922): avc: denied { read write } for pid=12151 comm="anacron" name="1" dev=devpts ino=3 scontext=root:system_r:system_crond_t tcontext=user_u:object_r:user_devpts_t tclass=chr_file Mar 15 15:12:54 topaz kernel: audit(1142435574.018:6923): avc: denied { use } for pid=12151 comm="anacron" name="1" dev=devpts ino=3 scontext=root:system_r:system_crond_t tcontext=user_u:user_r:user_t tclass=fd
which I think corresponds to the anacron processes being unable to write to the user_* FD's belonging to the shell which was used to invoke "sudo service". Since the AVC's are related to a user_* domain, I assume they are unrelated to the problem itself, which I imagine depends upon the interaction of the initrc_t, crond_t, and system_crond_t domains.
I'll try and perform a similar test with an enableaudit policy as soon as I can. Obviously, the log may take a bit of weeding!
============================== $ cat /etc/anacrontab # /etc/anacrontab: configuration file for anacron
# See anacron(8) and anacrontab(5) for details.
SHELL=/bin/sh PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root
1 5 anacron.daily run-parts /etc/anacron.daily 1 65 cron.daily run-parts /etc/cron.daily 7 70 cron.weekly run-parts /etc/cron.weekly 30 75 cron.monthly run-parts /etc/cron.monthly $
$ cat /etc/anacron.daily/0anacron #!/bin/sh # # anacron's cron script # # This script updates anacron time stamps. It is called through run-parts # either by anacron itself or by cron. # # The script is called "0anacron" to assure that it will be executed # _before_ all other scripts.
anacron -u anacron.daily
$ cat /etc/anacron.daily/mailcheck #!/bin/sh
echo "Testing Anacron Mail system"
cat /etc/resolv.conf
$
On Wed, 2006-03-15 at 08:51 -0500, Daniel J Walsh wrote:
Ted Rule wrote:
Something that's niggled me for a while are the empty Email messages generated by Anacron.
This is on FC4 / selinux-policy-strict-1.27.1-2.22
When the machine is left powered overnight, the normal /etc/cron.daily processes - including logwatch and logrotate - run perfectly happily and generate appropriate Emails.
By default, logrotate doesn't result in an Email, but for reasons unrelated to SELinux I have it set to run in debug mode, so my instance does. The Email from logrotate is effectively 'sent' by /etc/cron.daily as it wrappers all the output from its child jobs.
In contrast, logwatch sends its own Email independent of Cron's sendmail child process.
When the machine is depowered overnight and repowered in the morning, Anacron proceeds to run the various /etc/cron.daily scripts. With SELinux enforcing, logwatch runs normally, and generates its normal Email log summary.
However, logrotate's output is never seen, even though it can be seen from the various timestamps and filenames that logrotate has correctly run and suitably rotated all the logs.
The overall cron.daily Job launched by Anacron results in an empty Email, with no body and more particularly no Subject. The mail From address is set to "Anacron root@hostname".
Burrowing around the Anacron source it is apparent that under normal circumstances it would give the Email a subject of
"Anacron job cron.daily"
Given the behaviour I see, I think the problem is somehow related to the /etc/cron.daily/* processes not having rights to write to the file descriptor which is the input to Cron's overall sendmail process.
I've had a look through the SELinux policy to see if I can spot the difference between the permissions of Jobs launched by Cron and Anacron, and I'm afraid I can't see where the problem lies; since jobs launched by either method appear to run as system_crond_t, the difference in behaviour eludes me.
Can anyone else offer any insight into the problem?
Thanks,
Is this on FC5? If yes, are you seeing any AVC messages? If not could you attempt to enable audit
semodule -b /usr/share/selinux/targeted/enableaudit.pp
Create the error.
Grab the AVC Messages
semodule -b /usr/share/selinux/targeted/base.pp
to turn off auditing again.
Of course verifying this works with setenforce 0 would also help to make sure it is SELinux causing the problem.
Ted Rule wrote:
The host is FC4 rather than FC5testN
In order to avoid having to run in permissive overnight or completely reload the policy at the moment, I've run the following test:
Create new directory /etc/anacron.daily and a corresponding entry in /etc/anacrontab. Create /etc/anacron.daily/0anacron and a test job /etc/anacron.daily/mailcheck. ( See below )
Run in enforcing by restarting anacron service with
sudo service anacron start
Wait 5 mins for Job to run, and note that the resultant Email is empty-bodied as with /etc/cron.daily
Check anacron stopped.
Delete the timestamp file /var/spool/anacron/anacron.daily
Goto permissive with
sudo setenforce 0
Wait 5 mins for Job to run, and note that the resultant Email is properly formed with Subject and body as expected.
Go back to enforcing.
This all seems to confirm to me that SELinux policy is somehow blanking the body and subject. The only denial messages I see during in permissive state are these:
Mar 15 15:12:53 topaz sudo: ejtr : TTY=pts/1 ; PWD=/home/ejtr ; USER=root ; COMMAND=/sbin/service anacron start Mar 15 15:12:54 topaz kernel: audit(1142435574.018:6922): avc: denied { read write } for pid=12151 comm="anacron" name="1" dev=devpts ino=3 scontext=root:system_r:system_crond_t tcontext=user_u:object_r:user_devpts_t tclass=chr_file Mar 15 15:12:54 topaz kernel: audit(1142435574.018:6923): avc: denied { use } for pid=12151 comm="anacron" name="1" dev=devpts ino=3 scontext=root:system_r:system_crond_t tcontext=user_u:user_r:user_t tclass=fd
which I think corresponds to the anacron processes being unable to write to the user_* FD's belonging to the shell which was used to invoke "sudo service". Since the AVC's are related to a user_* domain, I assume they are unrelated to the problem itself, which I imagine depends upon the interaction of the initrc_t, crond_t, and system_crond_t domains.
I'll try and perform a similar test with an enableaudit policy as soon as I can. Obviously, the log may take a bit of weeding!
============================== $ cat /etc/anacrontab # /etc/anacrontab: configuration file for anacron
# See anacron(8) and anacrontab(5) for details.
SHELL=/bin/sh PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root
1 5 anacron.daily run-parts /etc/anacron.daily 1 65 cron.daily run-parts /etc/cron.daily 7 70 cron.weekly run-parts /etc/cron.weekly 30 75 cron.monthly run-parts /etc/cron.monthly $
$ cat /etc/anacron.daily/0anacron #!/bin/sh # # anacron's cron script # # This script updates anacron time stamps. It is called through run-parts # either by anacron itself or by cron. # # The script is called "0anacron" to assure that it will be executed # _before_ all other scripts.
anacron -u anacron.daily
$ cat /etc/anacron.daily/mailcheck #!/bin/sh
echo "Testing Anacron Mail system"
cat /etc/resolv.conf
$
Please enter a bugzilla so we don't loose this.
On Wed, 2006-03-15 at 08:51 -0500, Daniel J Walsh wrote:
Ted Rule wrote:
Something that's niggled me for a while are the empty Email messages generated by Anacron.
This is on FC4 / selinux-policy-strict-1.27.1-2.22
When the machine is left powered overnight, the normal /etc/cron.daily processes - including logwatch and logrotate - run perfectly happily and generate appropriate Emails.
By default, logrotate doesn't result in an Email, but for reasons unrelated to SELinux I have it set to run in debug mode, so my instance does. The Email from logrotate is effectively 'sent' by /etc/cron.daily as it wrappers all the output from its child jobs.
In contrast, logwatch sends its own Email independent of Cron's sendmail child process.
When the machine is depowered overnight and repowered in the morning, Anacron proceeds to run the various /etc/cron.daily scripts. With SELinux enforcing, logwatch runs normally, and generates its normal Email log summary.
However, logrotate's output is never seen, even though it can be seen from the various timestamps and filenames that logrotate has correctly run and suitably rotated all the logs.
The overall cron.daily Job launched by Anacron results in an empty Email, with no body and more particularly no Subject. The mail From address is set to "Anacron root@hostname".
Burrowing around the Anacron source it is apparent that under normal circumstances it would give the Email a subject of
"Anacron job cron.daily"
Given the behaviour I see, I think the problem is somehow related to the /etc/cron.daily/* processes not having rights to write to the file descriptor which is the input to Cron's overall sendmail process.
I've had a look through the SELinux policy to see if I can spot the difference between the permissions of Jobs launched by Cron and Anacron, and I'm afraid I can't see where the problem lies; since jobs launched by either method appear to run as system_crond_t, the difference in behaviour eludes me.
Can anyone else offer any insight into the problem?
Thanks,
Is this on FC5? If yes, are you seeing any AVC messages? If not could you attempt to enable audit
semodule -b /usr/share/selinux/targeted/enableaudit.pp
Create the error.
Grab the AVC Messages
semodule -b /usr/share/selinux/targeted/base.pp
to turn off auditing again.
Of course verifying this works with setenforce 0 would also help to make sure it is SELinux causing the problem.
Having run SELinux in enableaudit mode, I see this:
Mar 20 09:37:48 topaz kernel: audit(1142847445.519:9803): avc: denied { append } for pid=5507 comm="sendmail" name="fileVPVqYv" dev=hda10 ino=21 scontext=root:system_r:system_mail_t tcontext=root:object_r:system_crond_tmp_t tclass=file
A partial workround is thus to add this to policy:
# tail domains/misc/localpolicy.te ... allow system_mail_t { system_crond_tmp_t }:file { append }; #
Since sendmail has no legitimate reason to write to a system_crond_tmp_t file, the original SELinux policy is "correct", and this is only a workround.
After burrowing round the anacron source, I found that the problem arises because of the "dual-use" of a file-descriptor. anacron creates a temporary file, opens a file-descriptor read/write, unlinks the temporary filename, and then passes the FD as stdout/stderr to Job's it runs. Once the Jobs are complete, it passes the FD as stdin to sendmail.
The problem appears to be that SELinux complains when sendmail tries to use an inherited FD with write-permissions to a system_crond_tmp_t file.
Because the filename is unlinked after the file is opened, simply closing the FD and re-opening the temporary file read-only is not an option - or at least not a completely trivial one.
As a patch, therefore, I've tweaked anacron to open the temporary file twice - once write-only and once read-only - before unlinking the filename. The read-only FD is redirected to stdin, the write-only FD is closed, and stdout/stderr redirected to /dev/null before exec-ing sendmail.
This now added to Bugzilla as #185973 with an associated patch detailed therein.
On Thu, 2006-03-16 at 13:22 -0500, Daniel J Walsh wrote:
Ted Rule wrote:
The host is FC4 rather than FC5testN
In order to avoid having to run in permissive overnight or completely reload the policy at the moment, I've run the following test:
Create new directory /etc/anacron.daily and a corresponding entry in /etc/anacrontab. Create /etc/anacron.daily/0anacron and a test job /etc/anacron.daily/mailcheck. ( See below )
Run in enforcing by restarting anacron service with
sudo service anacron start
Wait 5 mins for Job to run, and note that the resultant Email is empty-bodied as with /etc/cron.daily
Check anacron stopped.
Delete the timestamp file /var/spool/anacron/anacron.daily
Goto permissive with
sudo setenforce 0
Wait 5 mins for Job to run, and note that the resultant Email is properly formed with Subject and body as expected.
Go back to enforcing.
This all seems to confirm to me that SELinux policy is somehow blanking the body and subject. The only denial messages I see during in permissive state are these:
Mar 15 15:12:53 topaz sudo: ejtr : TTY=pts/1 ; PWD=/home/ejtr ; USER=root ; COMMAND=/sbin/service anacron start Mar 15 15:12:54 topaz kernel: audit(1142435574.018:6922): avc: denied { read write } for pid=12151 comm="anacron" name="1" dev=devpts ino=3 scontext=root:system_r:system_crond_t tcontext=user_u:object_r:user_devpts_t tclass=chr_file Mar 15 15:12:54 topaz kernel: audit(1142435574.018:6923): avc: denied { use } for pid=12151 comm="anacron" name="1" dev=devpts ino=3 scontext=root:system_r:system_crond_t tcontext=user_u:user_r:user_t tclass=fd
which I think corresponds to the anacron processes being unable to write to the user_* FD's belonging to the shell which was used to invoke "sudo service". Since the AVC's are related to a user_* domain, I assume they are unrelated to the problem itself, which I imagine depends upon the interaction of the initrc_t, crond_t, and system_crond_t domains.
I'll try and perform a similar test with an enableaudit policy as soon as I can. Obviously, the log may take a bit of weeding!
============================== $ cat /etc/anacrontab # /etc/anacrontab: configuration file for anacron
# See anacron(8) and anacrontab(5) for details.
SHELL=/bin/sh PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root
1 5 anacron.daily run-parts /etc/anacron.daily 1 65 cron.daily run-parts /etc/cron.daily 7 70 cron.weekly run-parts /etc/cron.weekly 30 75 cron.monthly run-parts /etc/cron.monthly $
$ cat /etc/anacron.daily/0anacron #!/bin/sh # # anacron's cron script # # This script updates anacron time stamps. It is called through run-parts # either by anacron itself or by cron. # # The script is called "0anacron" to assure that it will be executed # _before_ all other scripts.
anacron -u anacron.daily
$ cat /etc/anacron.daily/mailcheck #!/bin/sh
echo "Testing Anacron Mail system"
cat /etc/resolv.conf
$
Please enter a bugzilla so we don't loose this.
On Wed, 2006-03-15 at 08:51 -0500, Daniel J Walsh wrote:
Ted Rule wrote:
Something that's niggled me for a while are the empty Email messages generated by Anacron.
This is on FC4 / selinux-policy-strict-1.27.1-2.22
When the machine is left powered overnight, the normal /etc/cron.daily processes - including logwatch and logrotate - run perfectly happily and generate appropriate Emails.
By default, logrotate doesn't result in an Email, but for reasons unrelated to SELinux I have it set to run in debug mode, so my instance does. The Email from logrotate is effectively 'sent' by /etc/cron.daily as it wrappers all the output from its child jobs.
In contrast, logwatch sends its own Email independent of Cron's sendmail child process.
When the machine is depowered overnight and repowered in the morning, Anacron proceeds to run the various /etc/cron.daily scripts. With SELinux enforcing, logwatch runs normally, and generates its normal Email log summary.
However, logrotate's output is never seen, even though it can be seen from the various timestamps and filenames that logrotate has correctly run and suitably rotated all the logs.
The overall cron.daily Job launched by Anacron results in an empty Email, with no body and more particularly no Subject. The mail From address is set to "Anacron root@hostname".
Burrowing around the Anacron source it is apparent that under normal circumstances it would give the Email a subject of
"Anacron job cron.daily"
Given the behaviour I see, I think the problem is somehow related to the /etc/cron.daily/* processes not having rights to write to the file descriptor which is the input to Cron's overall sendmail process.
I've had a look through the SELinux policy to see if I can spot the difference between the permissions of Jobs launched by Cron and Anacron, and I'm afraid I can't see where the problem lies; since jobs launched by either method appear to run as system_crond_t, the difference in behaviour eludes me.
Can anyone else offer any insight into the problem?
Thanks,
Is this on FC5? If yes, are you seeing any AVC messages? If not could you attempt to enable audit
semodule -b /usr/share/selinux/targeted/enableaudit.pp
Create the error.
Grab the AVC Messages
semodule -b /usr/share/selinux/targeted/base.pp
to turn off auditing again.
Of course verifying this works with setenforce 0 would also help to make sure it is SELinux causing the problem.
selinux@lists.fedoraproject.org