This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 789165 - File locking problem with /bin/mail when -f option is used
File locking problem with /bin/mail when -f option is used
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: mailx (Show other bugs)
5.7
x86_64 Linux
unspecified Severity medium
: rc
: ---
Assigned To: Peter Schiffer
qe-baseos-daemons
: EasyFix, Patch
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-02-09 19:31 EST by Ken Nishimura
Modified: 2013-04-12 16:57 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-03-11 08:01:02 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
mailx-8.1.1-quit.patch (640 bytes, patch)
2013-01-10 10:47 EST, Peter Schiffer
no flags Details | Diff

  None (edit)
Description Ken Nishimura 2012-02-09 19:31:41 EST
Description of problem:
Migrating from RHEL4 to RHEL5, we have noticed an issue with /bin/mail, provided by package: mailx-8.1.1-44.2.2 The way to reproduce this problem is to open a mail spool file located in a non-standard location using the -f option. While /bin/mail is running and the non-standard mail spool is open, if one modifies the spool at the same time that new mail arrives, upon quitting, the program responds with: /tmp/mboxXXXXXX: File exists where XXXXXX is an unique identifier issued by mkstemp() Another attempt to quit results in: *** stack smashing detected ***: mail terminated 

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

mailx-8.1.1-44.2.2

How reproducible:

Consistent

Steps to Reproduce:
1) Execute /bin/mail -f mail_spool_file (this cannot be the default system mailbox) 
2) Delete any message using the "d" command 
3) While this program is running, cause additional mail to be appended to mail_spool_file (e.g. cat mail_data >> mail_spool_file) 
4) Attempt to quit the mail program using the "q" command.
  
Actual results:
/tmp/mboxXXXXXX: File exists where XXXXXX is an unique identifier issued by mkstemp() Another attempt to quit results in: *** stack smashing detected ***: mail terminated 

Expected results:

Mail program terminates normally

Additional info:
Where I have gotten so far: 
* Between EL4 and EL5, a patch has been included that modifies quit.c. Basically, instead of using the "dangerous" tmpname() call, it uses mkstemp().

* mkstemp returns a file descriptor AND apparently opens the file with flags O_EXCL. Immediately after calling mkstemp(), the code in quit.c attempts an fopen of the file in "w" mode. This fails, probably due to the exclusive open, and the error code is generated by perror(). Because file locking is so important in /bin/mail, I will leave it to the experts to come up with a suitable patch. I have verified that reverting back to the use of tmpname() instead of mkstemp() does clear the bug, but if mkstemp() is preferred, some other patch needs to be devised. Simply using close() didn't seem to work. 

This impacts the use of /bin/mail in scripts with the -f option.
Comment 1 RHEL Product and Program Management 2012-06-11 21:31:07 EDT
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.
Comment 2 Peter Schiffer 2013-01-10 10:47:19 EST
Created attachment 676398 [details]
mailx-8.1.1-quit.patch
Comment 3 Peter Schiffer 2013-01-10 10:52:28 EST
Hi Ken,

thanks for detailed description! I back-ported fix from bsd-mailx 8.1.2, patch is attached. Also, here is the test package for you to test:
https://dl.dropbox.com/u/15321270/mailx-8.1.1-44.2.2.1.x86_64.rpm

What do you think?

peter
Comment 4 Ken Nishimura 2013-01-10 16:42:07 EST
(In reply to comment #3)
> Hi Ken,
> 
> thanks for detailed description! I back-ported fix from bsd-mailx 8.1.2,
> patch is attached. Also, here is the test package for you to test:
> https://dl.dropbox.com/u/15321270/mailx-8.1.1-44.2.2.1.x86_64.rpm
> 
> What do you think?
> 
> peter

:-)

After 11 months, I thought this was forgotten!  Thanks for putting the backport in.  It seems to behave properly.

Thanks,

Ken (probably the only one who still uses /bin/mailx)
Comment 5 Peter Schiffer 2013-03-11 08:01:02 EDT
Ken,

we are sorry, but it is too late in the RHEL-5 development cycle for us to address this issue in the coming RHEL-5 minor release. You can use the test package as long as you wish, but I'm afraid I can't help you any other way.

peter

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