Red Hat Bugzilla – Bug 460873
At does not deliver mail
Last modified: 2008-10-08 14:41:28 EDT
Description of problem:
The output of at commands are not delivered as mail.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Schedule an at command that writes something, say "echo apa"
2. Wait for a mail with the text "apa"
This is SELinux related. If I run in permissive mode, the mail arrives. But there is no AVC messages, so it is not the policy directly preventing the operation.
In /var/log/messages there comes a message like this for every at job:
Sep 2 11:23:00 mimmi atd: Not allowed to set exec context to user_u:user_r:system_chkpwd_t for user göran : Unknown error 18446744073709551594
One obvious error here is to try to use errno after an operation that doesn't set errno to anything reasonable. (This syslog message may not be related to the missing mails. But since this message comes from the patch adding a lot of SELinux code, I suspect there is a connection.)
Following the reproducer:
Sep 3 10:11:33 caladan atd: Not allowed to set exec context to user_u:user_r:system_chkpwd_t:s0 for user marca#012: No such file or directory
/var/log/audit is attached as audit.log
nothing in /var/log/messages
/var/log/audit is attached as audit2.log
Created attachment 315625 [details]
Created attachment 315626 [details]
You can add these rules for now using
# grep avc /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp
Fixed in selinux-policy-3.3.1-88.fc9
Eh, Daniel, exactly what did you add to "fix" this in 3.3.1-88.fc9?
Note that in the first audit log (315625) there are NO avc messages. And that is the case that fails.
In the second audit log there are avc failures. And it might be that those would actually have blocked the functionality if they had been enforced. But in enforcing mode the application doesn't even try those operations!
I maintain that the primary problem here is in the application (at), not in the policy. And I suspect the patch to the upstreams package that adds a lot of SELinux aware code. In particular, there are several tests to check if the mode is enforcing or not. So the application is actually programmed to behave differently in enforcing and permissive mode.
When this problem is fixed, there may or may not be things that have to be changed in the policy too.
I have allowed sendmail to read cron spool files.
Policy is now available in koji if you want to try it out.
I picked up selinux-policy-3.3.1-90.fc9 from Koji. I still don't get any mail. In permissive mode, I no longer get any avc denials, but in enforcing mode no mail is delivered anyway.
I still believe this is a bug in at, not in selinux-policy.
Sorry, I didn't mean to take you out of the loop Daniel. That was an unintentional side-effect when I assigned the bug back to the at component.
Anyway, I downloaded at-debuginfo and made a bit of debugging. What happens is this:
The command gets executed properly and a file with the intended mail message is created. But things gets wrong when this mail is to be sent. The relevant code is in the "if ( mail_pid == 0 )" of run_file() in atd.c.
First it does a
get_default_context("myuser", NULL, &user_context)
and gets "user_u:user_r:system_chkpwd_t" in user_context. (Is this correct? Should system_chkpwd_t be the type one gets as the default?)
Then it does an
and gets "unconfined_u:object_r:cron_spool_t" back. Standard input contains the message that is to be sent.
In the next step it checks to see if this user is allowed to enter(!) this file:
In the result, avd.allowed=0. The code then verifies that FILE__ENTRYPOINT is in avd.allowed, which it isn't, and gives up instead of sending the mail.
I'm not sure if the syste_chkpwd_t default context is corret, or if I have made some mistake which makes this the default. But in any case it doesn't seem sensible to test for entrypoint permission to the file which contains the message to be sent. That is pure data!
Created attachment 316674 [details]
Attempted module to allow the accesses.
I tried to make a policy to verify my reasoning. By allowing system_chkpwd_t entrypoint access to cron_spool_t:file the code doesn't stop, and launches sendmail to send the message. But first it does an setexeccon() to system_chkpwd_t, and that domain is what sendmail runs in. That doesn't work too well it seems. I tried to make the process transition into the sendmail_t domain when executing sendmail, but I must be doing something wrong.
But this isn't too important, I guess. This shouldn't be allowed, the bug is in the atd code which requests it to be allowed. Or am I completely confused here?
No it should not be running in system_chkpwd_t.
when you setup cron job?
# semanage login -l
# semanage user -l
When I ran "id -Z as a cron job, I get
The other commands below:
mimmi# env LANG=en_US.utf8 semanage login -l
Login Name SELinux User MLS/MCS Range
__default__ unconfined_u SystemLow-SystemHigh
root unconfined_u s0-s0:c0.c255
system_u system_u SystemLow-SystemHigh
mimmi# env LANG=en_US.utf8 semanage user -l
Labeling MLS/ MLS/
SELinux User Prefix MCS Level MCS Range SELinux Roles
root user s0 SystemLow-SystemHigh system_r staff_r unconfined_r sysadm_r
staff_u user s0 SystemLow-SystemHigh system_r staff_r sysadm_r
sysadm_u user s0 SystemLow-SystemHigh sysadm_r
system_u user s0 SystemLow-SystemHigh system_r
unconfined_u unconfined s0 SystemLow-SystemHigh system_r unconfined_r
user_u user s0 s0 user_r
Created attachment 316856 [details]
Rewrote the SELinux patch to be shared between the job and the email
Please apply this patch to F9/Rawhide.
Not sure if this is broken in RHEL5 also.
Thank you for the patch.
at-3.1.10-24.fc9 has been submitted as an update for Fedora 9.
I picked up at-3.1.10-24.fc9 from Koji and tried it, and it worked fine! I got the expected mail this time.
I did make a try on my RHEL5 desktop at work, and it does NOT seem to have the problem. (at-3.1.8-82.fc6)
at-3.1.10-24.fc9 has been pushed to the Fedora 9 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update at'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-8251
*** Bug 460252 has been marked as a duplicate of this bug. ***
at-3.1.10-24.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.
at-3.1.10-24.fc9 works fine.
I did note that at-3.1.10-24.fc10 does not work. I thought it was the same "24", but apparently it's different branches somehow. Just thought I'd mention it so this doesn't reappear in F10 by mistake. (RPM considers at-3.1.10-24.fc10 newer than at-3.1.10-24.fc9.)