Bug 1202562

Summary: esmtp should not depend on $HOME being set
Product: [Fedora] Fedora Reporter: Van de Bugger <van.de.bugger>
Component: esmtpAssignee: Jaroslav Škarvada <jskarvad>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: antti16+redhat, itamar, jskarvad, mikhail.v.gavrilov, mmaslano, olysonek, pertusus, smparrish, tmraz, van.de.bugger
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-12-21 20:27:32 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Van de Bugger 2015-03-16 21:45:30 UTC
Description of problem:

When cronie sends program output to root, by default it uses /usr/sbin/sendmail. In Fedora 21, by default, /usr/sbin/sendmail is a symlink to /etc/alternatives/mta, which is a symlink to /usr/bin/esmtp-wrapper. The latter is a bash script, which uses HOME environment variable:

> qdir="$HOME/.esmtp_queue"

qdir variable is used as a name of directory to create messages in.

Up to this point everything is ok. But, when cronie runs /usr/bin/esmtp-wrapper (trough /usr/sbin/sendmail symlink), HOME environment variable is NOT defined. Thus, esmtp-wrapper creates directory "/.esmtp_queue" (NOTE: in root directory, NOT in root home!), then SELinux prevents esmtp from reading files in "/.esmtp", see bug 544603. 544603 is closed because it is not a problem of SELinuix; however, it IS a problem of cronie, or incompatibility between cronie and esmtp.

Adding HOME=/root to crontab file does not help: Environment variables defined in crontab file are set for cron job, NOT for sendmail.

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

Fedora 21
cronie-1.4.12-1.fc21.x86_64
esmtp-1.0-13.fc21.x86_64

How reproducible:

Always.

Steps to Reproduce:

Make sure esmtp and cronie are installed. Make sure cronie is active.

# echo "mm hh * * * root echo AAAAAAAAAAAAAAAAAAAAAAAAAAAAA" > /etc/cron.d/test

where mm and hh is a time in nearest future. Wait for that time.

Actual results:

"/.esmtp_queue" directory created, SELinux shows alert that process esmpt tries to read file "/.esmtp_queue/.../mail".

Expected results:

"/.esmtp_queue" directory is NOT created; there is NO SELinux alerts; message with content "AAAAAAAAAAAAAAAAAAAAAAAAAAAAA" is sent to root.

Comment 1 Van de Bugger 2015-03-16 22:19:03 UTC
Alternative view:

It could be treated as esmtp bug. esmtp-wrapper could be more smart and do not rely on HOME environment variable, for example, instead of plain

> qdir="$HOME/.esmtp_queue"

it could use something like this:

> HOME=${HOME:-$(getent passwd $(id -u) | cut -d: -f6)}
> qdir="$HOME/.esmtp_queue"
 
If you thin so, please reassign the bug to esmtp.

Comment 2 Van de Bugger 2015-03-16 22:54:25 UTC
Sorry for the third message, but there is another, easier (easiest?) way to fix esmtp-wrapper:

> qdir=~/.esmtp_queue

Bash does tilde expansion even if HOME is not set.

Comment 3 Van de Bugger 2015-07-06 18:30:10 UTC
The problem still exists in F22.

Installing clamav-update adds a cronie job, which sends messages to root. However, due to this bug, all the messages are created /.esmtp_queue directory, which are not delivered, because SELinux blocks does not allow esmtp read this directory, so root has lot of SELinux alerts instead of messages. These SELinux alerts could be a bit frightening for inexperienced user.

Comment 4 Fedora End Of Life 2015-11-04 10:42:24 UTC
This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. 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 EOL if it remains open with a Fedora  'version'
of '21'.

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.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 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 this bug is closed as described in the policy above.

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.

Comment 5 Fedora End Of Life 2016-11-24 11:34:10 UTC
This message is a reminder that Fedora 23 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 23. 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 EOL if it remains open with a Fedora  'version'
of '23'.

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.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 23 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 this bug is closed as described in the policy above.

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.

Comment 6 Ondřej Lysoněk 2016-12-20 13:09:34 UTC
I think this should now be fixed in F23 to Rawhide. Can you confirm?

Comment 7 Van de Bugger 2016-12-21 19:58:04 UTC
> I think this should now be fixed in F23 to Rawhide. Can you confirm?

Not sure about all the range from F23..F25, but esmtp-1.2-4.fc24.x86_64 looks like fixed:

> ID=`id -un`
> [ "$HOME" ] || HOME=`getent passwd $ID | cut -d: -f6`
> qdir="$HOME/.esmtp_queue"

(My proposal (qdir=~/.esmtp_queue) is simpler, but I do not care too much.)