Bug 460873 - At does not deliver mail
At does not deliver mail
Product: Fedora
Classification: Fedora
Component: at (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Marcela Mašláňová
Fedora Extras Quality Assurance
: 460252 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2008-09-02 05:33 EDT by Göran Uddeborg
Modified: 2008-10-08 14:41 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-10-03 18:29:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
audit (3.75 KB, text/plain)
2008-09-03 05:11 EDT, Marcela Mašláňová
no flags Details
audit (6.74 KB, text/plain)
2008-09-03 05:11 EDT, Marcela Mašláňová
no flags Details
Attempted module to allow the accesses. (408 bytes, text/plain)
2008-09-13 16:44 EDT, Göran Uddeborg
no flags Details
Rewrote the SELinux patch to be shared between the job and the email (7.38 KB, application/octet-stream)
2008-09-16 11:06 EDT, Daniel Walsh
no flags Details

  None (edit)
Description Göran Uddeborg 2008-09-02 05:33:05 EDT
Description of problem:
The output of at commands are not delivered as mail.

Version-Release number of selected component (if applicable):

How reproducible:
Every time

Steps to Reproduce:
1. Schedule an at command that writes something, say "echo apa"
2. Wait for a mail with the text "apa"
Actual results:
No mail

Expected results:
A mail

Additional info:
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[19765]: 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.)
Comment 1 Marcela Mašláňová 2008-09-03 05:10:35 EDT
Following the reproducer:
setenforce 1
Sep  3 10:11:33 caladan atd[2768]: 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

setenforce 0
nothing in /var/log/messages
/var/log/audit is attached as audit2.log
Comment 2 Marcela Mašláňová 2008-09-03 05:11:28 EDT
Created attachment 315625 [details]
Comment 3 Marcela Mašláňová 2008-09-03 05:11:53 EDT
Created attachment 315626 [details]
Comment 4 Daniel Walsh 2008-09-03 13:58:35 EDT
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
Comment 5 Göran Uddeborg 2008-09-03 15:48:32 EDT
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.
Comment 6 Daniel Walsh 2008-09-03 16:56:51 EDT
I have allowed sendmail to read cron spool files.
Comment 7 Daniel Walsh 2008-09-03 16:57:54 EDT
Policy is now available in koji if you want to try it out.
Comment 8 Göran Uddeborg 2008-09-13 14:46:56 EDT
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.
Comment 9 Göran Uddeborg 2008-09-13 16:37:05 EDT
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
   fgetfilecon(STDIN_FILENO, &file_context)
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!
Comment 10 Göran Uddeborg 2008-09-13 16:44:26 EDT
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?
Comment 11 Daniel Walsh 2008-09-15 14:12:37 EDT
No it should not be running in system_chkpwd_t.

What does 
id -Z 
when you setup cron job?

# semanage login -l
# semanage user -l
Comment 12 Göran Uddeborg 2008-09-15 15:06:05 EDT
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
Comment 13 Daniel Walsh 2008-09-16 11:06:25 EDT
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.
Comment 14 Marcela Mašláňová 2008-09-17 04:53:54 EDT
Thank you for the patch.
Comment 15 Fedora Update System 2008-09-17 05:07:23 EDT
at-3.1.10-24.fc9 has been submitted as an update for Fedora 9.
Comment 16 Göran Uddeborg 2008-09-17 15:27:07 EDT
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)
Comment 17 Fedora Update System 2008-09-24 20:12:04 EDT
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
Comment 18 Daniel Walsh 2008-10-02 08:38:03 EDT
*** Bug 460252 has been marked as a duplicate of this bug. ***
Comment 19 Fedora Update System 2008-10-03 18:29:53 EDT
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.
Comment 20 Göran Uddeborg 2008-10-08 14:41:28 EDT
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.)

Note You need to log in before you can comment on or make changes to this bug.