Hide Forgot
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.
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.
Created attachment 676398 [details] mailx-8.1.1-quit.patch
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
(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)
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