Bug 919038

Any idea why mailx would attempt to create a file in /?

Cremonini,

please, are you able to identify what is running mailx after boot? Is this machine set up as server? Do you have some monitoring tool, custom script, service, etc.. which might be using mailx?

Please, also attach /etc/mail.rc file.

Thanks,

peter

Hey Peter,

No, this is not a server. This machine is my desktop. 

The bug happens every time after the login finished. It's weird because i never set up anything on mailx. It's on default config.

I do not running any kind of scrits/service about that.

Below, my mail.rc config.

PS: Sorry my poor english.



$ cat /etc/mail.rc 
# This is the configuration file for Heirloom mailx (formerly
# known under the name "nail".
# See mailx(1) for further options.
# This file is not overwritten when 'make install' is run in
# the mailx build process again.

# Sccsid @(#)nail.rc	2.11 (gritter) 8/2/08

# Do not forward to mbox by default since this is likely to be
# irritating for most users today.
set hold

# Append rather than prepend when writing to mbox automatically.
# This has no effect unless 'hold' is unset again.
set append

# Ask for a message subject.
set ask

# Assume a CRT-like terminal and invoke a pager.
set crt

# Messages may be terminated by a dot.
set dot

# Do not remove empty mail folders in the spool directory.
# This may be relevant for privacy since other users could
# otherwise create them with different permissions.
set keep

# Do not remove empty private mail folders.
set emptybox

# Quote the original message in replies by "> " as usual on the Internet.
set indentprefix="> "

# Automatically quote the text of the message that is responded to.
set quote

# Outgoing messages are sent in ISO-8859-1 if all their characters are
# representable in it, otherwise in UTF-8.
set sendcharsets=iso-8859-1,utf-8

# Display sender's real names in header summaries.
set showname

# Display the recipients of messages sent by the user himself in
# header summaries.
set showto

# Automatically check for new messages at each prompt, but avoid polling
# of IMAP servers or maildir folders.
set newmail=nopoll

# If threaded mode is activated, automatically collapse thread.
set autocollapse

# Mark messages that have been answered.
set markanswered

# Hide some header fields which are uninteresting for most human readers.
ignore received in-reply-to message-id references
ignore mime-version content-transfer-encoding

# Only include selected header fields when forwarding messages.
fwdretain subject date from to

# For Linux and BSD, this should be set.
set bsdcompat





Thanks,

Cremonini

Description of problem:
1. Boot up the system

Additional info:
hashmarkername: setroubleshoot
kernel:         3.8.8-202.fc18.x86_64
type:           libreport

Cremonini, Alexander,

thanks for the provided information. So far I have no idea what's the problem, so let's try to figure it out. (If you still see the problem.)

First of all, please confirm that the problem appears always after login: log out and log in, at least twice, and see if the problem appears after every login, not only after first login after boot.

Then, please attach sosreport created right after the problem occurred. (Sosreport can be created by running "# sosreport" command as root.)

After that, will see what to do next.

Thanks guys.

peter

I would figure this is mailx running within an init script and not having it's homedir set, so it defaults to / to write its content.

Guys,

can you still reproduce the problem? If we prepare some test builds, can you try them whether they fix the problem?

Thanks,

peter

I can confirm this also on Fedora 19 32bit (3.10.7-200.fc19.i686.PAE)

I have a script which i created under /etc/NetworkManager/dispatcher.d/ to send emails whenever there is a change in interface status. I used it before on F18 (but I believe SELinux was disabled at that time) and now i get the same alert whenever NM tries to execute that script:
"SELinux is preventing /usr/bin/mailx from write access on the directory /"

so I tried to run the script manually and I got a different alert:
"SELinux is preventing /usr/bin/mailx from create access on the file dead.letter"

However, when I copied the script file to my home folder (and even the root folder/ ) it worked with no issues!

Does the mail get sent even with the the failure?  What is the value of $HOME when networkmanager executes the script?

No it doesn't send the email
$HOME is empty or NULL (an echo from the script returns "")

I also saw these two messages (from /var/log/messages) which seems to be reported by mailx:

nm-dispatcher.action[15106]: Error initializing NSS: Unknown error -8015.
nm-dispatcher.action[15106]: . . . message not sent.

So should I set $HOME with something like /tmp in the script?

If you set 

export HOME=/root

Does that fix the problem.

No, I got the same two messages as above and SELinux is now saying:
"SELinux is preventing /usr/bin/mailx from create access on the file dead.letter"

since mailx is not suppose to write to root folder.

I used HOME=/tmp and the dead.letter got created.

By the way, I should mention that my SMTP server which I am trying to connect to uses SSL (smtps) and that is why it needs the NSS. So in my case it might not be SELinux that is causing the problem, it could be something else but SELinux is just preventing it from writing the dead.letter once it fails.

It is SELinux that is stopping it since after I changed it from "Enforcing" to "Permissive" the email got sent and Selinux reported some more messages:

SELinux is preventing /usr/bin/mailx from getattr access on the file /etc/openldap/certs/secmod.db
SELinux is preventing /usr/bin/mailx from read access on the file /etc/openldap/certs/secmod.db

this permission is needed for SSL certificate access.

by the way, mailx was able to send the email even without "export HOME...."

Please attach the AVC messages you are now getting.

ausearch -m avc -ts recent

# ausearch -m avc -ts recent


----
time->Wed Sep 25 13:10:37 2013
type=SYSCALL msg=audit(1380129037.616:707): arch=40000003 syscall=5 success=yes exit=4 a0=93f6008 a1=0 a2=180 a3=93f6420 items=0 ppid=1 pid=3368 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="mailx" exe="/usr/bin/mailx" subj=system_u:system_r:sendmail_t:s0 key=(null)
type=AVC msg=audit(1380129037.616:707): avc:  denied  { open } for  pid=3368 comm="mailx" path="/etc/openldap/certs/secmod.db" dev="sda10" ino=2098536 scontext=system_u:system_r:sendmail_t:s0 tcontext=unconfined_u:object_r:slapd_cert_t:s0 tclass=file
type=AVC msg=audit(1380129037.616:707): avc:  denied  { read } for  pid=3368 comm="mailx" name="secmod.db" dev="sda10" ino=2098536 scontext=system_u:system_r:sendmail_t:s0 tcontext=unconfined_u:object_r:slapd_cert_t:s0 tclass=file
----
time->Wed Sep 25 13:10:37 2013
type=SYSCALL msg=audit(1380129037.616:706): arch=40000003 syscall=195 success=yes exit=0 a0=93f6008 a1=bf8e4230 a2=44e38000 a3=93f6420 items=0 ppid=1 pid=3368 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="mailx" exe="/usr/bin/mailx" subj=system_u:system_r:sendmail_t:s0 key=(null)
type=AVC msg=audit(1380129037.616:706): avc:  denied  { getattr } for  pid=3368 comm="mailx" path="/etc/openldap/certs/secmod.db" dev="sda10" ino=2098536 scontext=system_u:system_r:sendmail_t:s0 tcontext=unconfined_u:object_r:slapd_cert_t:s0 tclass=file

Is the mail program actually mailing these files or is this some kinde of interaction with openldap causing it?

These are files that mailx need to access to verify the SSL certificates when communicating over encrypted channels. And there are many locations where you can find such files depending on the packages you have installed on your distro. For example Openldap will create its own under /etc/openldap/cert, NSS will be under /etc/pki/nssdb/ and even Firefox creates its own under the user profile.

Then you pass the folder that has such valid cert*db to mailx string option "nss-config-dir"

So for a single user I can configure SELinux to allow mailx to have access to the folder that I know exist on my system. But how can this be done to suite all users? and is there any risk in enabling read access to most possible places that provide cert files?

This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

abrt could run mailx after reboot, especially when a vmcore is detected.

Description of problem:
I dont know haw it's appens sorry.. I have just make a cleanup with bleachbit and update some pâckages..

Additional info:
reporter:       libreport-2.1.11
hashmarkername: setroubleshoot
kernel:         3.12.8-300.fc20.i686+PAE
type:           libreport

Description of problem:
Installed apcupsd, and cut power to the UPS.

Instead of getting an e-mail alert, the e-mail was blocked by an SELinux denial.

Additional info:
reporter:       libreport-2.1.11
hashmarkername: setroubleshoot
kernel:         3.12.7-300.fc20.x86_64
type:           libreport

Description of problem:
I have complitely no idea why this error came up /

Additional info:
reporter:       libreport-2.1.11
hashmarkername: setroubleshoot
kernel:         3.12.9-301.fc20.x86_64
type:           libreport

Could you attach the AVC's you are seeing?

(In reply to Daniel Walsh from comment #23)
> Could you attach the AVC's you are seeing?

SELinux is preventing /usr/bin/mailx from 'write' accesses on the directory /.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that mailx should be allowed write access on the  directory by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# grep mail /var/log/audit/audit.log | audit2allow -M mypol
# semodule -i mypol.pp

Additional Information:
Source Context                system_u:system_r:system_mail_t:s0
Target Context                system_u:object_r:root_t:s0
Target Objects                / [ dir ]
Source                        mail
Source Path                   /usr/bin/mailx
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           mailx-12.5-10.fc20.x86_64
Target RPM Packages           filesystem-3.2-19.fc20.x86_64
Policy RPM                    selinux-policy-3.12.1-119.fc20.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 3.12.9-301.fc20.x86_64 #1 SMP Wed
                              Jan 29 15:56:22 UTC 2014 x86_64 x86_64
Alert Count                   10
First Seen                    2014-02-01 21:28:13 PST
Last Seen                     2014-02-04 22:39:28 PST
Local ID                      db958f50-0efc-4546-9368-8a36b1957732

Raw Audit Messages
type=AVC msg=audit(1391582368.579:42): avc:  denied  { write } for  pid=845 comm="mail" name="/" dev="dm-1" ino=2 scontext=system_u:system_r:system_mail_t:s0 tcontext=system_u:object_r:root_t:s0 tclass=dir


type=SYSCALL msg=audit(1391582368.579:42): arch=x86_64 syscall=open success=no exit=EACCES a0=1688750 a1=441 a2=1b6 a3=7fffe62a4a60 items=0 ppid=1 pid=845 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm=mail exe=/usr/bin/mailx subj=system_u:system_r:system_mail_t:s0 key=(null)

Hash: mail,system_mail_t,root_t,dir,write

(In reply to quickbooks.office from comment #24)
> (In reply to Daniel Walsh from comment #23)
> > Could you attach the AVC's you are seeing?
> 
> SELinux is preventing /usr/bin/mailx from 'write' accesses on the directory
> /.
> 
> *****  Plugin catchall (100. confidence) suggests  
> **************************
> 
> If you believe that mailx should be allowed write access on the  directory
> by default.
> Then you should report this as a bug.
> You can generate a local policy module to allow this access.
> Do
> allow this access for now by executing:
> # grep mail /var/log/audit/audit.log | audit2allow -M mypol
> # semodule -i mypol.pp
> 
> Additional Information:
> Source Context                system_u:system_r:system_mail_t:s0
> Target Context                system_u:object_r:root_t:s0
> Target Objects                / [ dir ]
> Source                        mail
> Source Path                   /usr/bin/mailx
> Port                          <Unknown>
> Host                          (removed)
> Source RPM Packages           mailx-12.5-10.fc20.x86_64
> Target RPM Packages           filesystem-3.2-19.fc20.x86_64
> Policy RPM                    selinux-policy-3.12.1-119.fc20.noarch
> Selinux Enabled               True
> Policy Type                   targeted
> Enforcing Mode                Enforcing
> Host Name                     (removed)
> Platform                      Linux (removed) 3.12.9-301.fc20.x86_64 #1 SMP
> Wed
>                               Jan 29 15:56:22 UTC 2014 x86_64 x86_64
> Alert Count                   10
> First Seen                    2014-02-01 21:28:13 PST
> Last Seen                     2014-02-04 22:39:28 PST
> Local ID                      db958f50-0efc-4546-9368-8a36b1957732
> 
> Raw Audit Messages
> type=AVC msg=audit(1391582368.579:42): avc:  denied  { write } for  pid=845
> comm="mail" name="/" dev="dm-1" ino=2
> scontext=system_u:system_r:system_mail_t:s0
> tcontext=system_u:object_r:root_t:s0 tclass=dir
> 
> 
> type=SYSCALL msg=audit(1391582368.579:42): arch=x86_64 syscall=open
> success=no exit=EACCES a0=1688750 a1=441 a2=1b6 a3=7fffe62a4a60 items=0
> ppid=1 pid=845 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0
> sgid=0 fsgid=0 ses=4294967295 tty=(none) comm=mail exe=/usr/bin/mailx
> subj=system_u:system_r:system_mail_t:s0 key=(null)
> 
> Hash: mail,system_mail_t,root_t,dir,write

(In reply to Daniel Walsh from comment #23)
> Could you attach the AVC's you are seeing?

I am sorry for stupid question Daniel but what is AVC and how to get it?
I am really new in BugZilla and Fedora.

AVC's are SELinux error messages.  

ausearch -m avc 

Will get you all of your AVC messages.

Description of problem:
Occured during RDO installation. 

Additional info:
reporter:       libreport-2.1.12
hashmarkername: setroubleshoot
kernel:         3.13.5-200.fc20.x86_64
type:           libreport

I'm seeing messages like this too.  Here's the result of ausearch -m avc trimmed to just the most recent boot:

----
time->Mon Mar 17 11:02:39 2014
type=SYSCALL msg=audit(1395068559.025:408): arch=c000003e syscall=2 success=no exit=-13 a0=f980c8 a1=441 a2=1b6 a3=c items=0 ppid=2618 pid=2619 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="mailx" exe="/usr/bin/mailx" subj=system_u:system_r:sendmail_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1395068559.025:408): avc:  denied  { write } for  pid=2619 comm="mailx" name="ccpp-2014-03-17-11:02:32-1787" dev="dm-0" ino=2498303 scontext=system_u:system_r:sendmail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:abrt_var_cache_t:s0 tclass=dir
----
time->Mon Mar 17 11:02:51 2014
type=SYSCALL msg=audit(1395068571.061:409): arch=c000003e syscall=2 success=no exit=-13 a0=d1c0c8 a1=441 a2=1b6 a3=c items=0 ppid=2685 pid=2686 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="mailx" exe="/usr/bin/mailx" subj=system_u:system_r:sendmail_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1395068571.061:409): avc:  denied  { write } for  pid=2686 comm="mailx" name="ccpp-2014-03-17-11:02:32-2162" dev="dm-0" ino=2498338 scontext=system_u:system_r:sendmail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:abrt_var_cache_t:s0 tclass=dir
----
time->Mon Mar 17 11:15:14 2014
type=SYSCALL msg=audit(1395069314.941:416): arch=c000003e syscall=2 success=no exit=-13 a0=7ffffe09b000 a1=80800 a2=7ffffe09b000 a3=3c items=0 ppid=1 pid=1417 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="acpid" exe="/usr/sbin/acpid" subj=system_u:system_r:apmd_t:s0 key=(null)
type=AVC msg=audit(1395069314.941:416): avc:  denied  { read } for  pid=1417 comm="acpid" name="event22" dev="devtmpfs" ino=22434 scontext=system_u:system_r:apmd_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=chr_file
----
time->Mon Mar 17 11:16:43 2014
type=SYSCALL msg=audit(1395069403.650:436): arch=c000003e syscall=2 success=no exit=-13 a0=20460c8 a1=441 a2=1b6 a3=c items=0 ppid=4789 pid=4790 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="mailx" exe="/usr/bin/mailx" subj=system_u:system_r:sendmail_t:s0-s0:c0.c1023 key=(null)
type=AVC msg=audit(1395069403.650:436): avc:  denied  { write } for  pid=4790 comm="mailx" name="ccpp-2014-03-17-11:16:27-2789" dev="dm-0" ino=2498302 scontext=system_u:system_r:sendmail_t:s0-s0:c0.c1023 tcontext=system_u:object_r:abrt_var_cache_t:s0 tclass=dir
[root@grograman ~]#

Your AVC's have nothing to do with the original. You seem to have tools writing to the abrt_var_chach directory and you have an AVC that is showing a race condition on the labeling of /dev/event22.

Description of problem:
I have a user crontab executing, and mailx generates and appends to dead.letter file in the user's home directory,

Additional info:
reporter:       libreport-2.2.2
hashmarkername: setroubleshoot
kernel:         3.14.4-200.fc20.x86_64
type:           libreport