Bug 142860 - /bin/mail run from within a cronjob fails if nscd is not running and nss_ldap is used
/bin/mail run from within a cronjob fails if nscd is not running and nss_ldap...
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: mailx (Show other bugs)
2.1
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Ivana Varekova
:
Depends On:
Blocks: 132991
  Show dependency treegraph
 
Reported: 2004-12-14 13:36 EST by James Bourne
Modified: 2007-11-30 17:06 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-07-23 08:44:46 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
contains 3 backtraces and an ldap.conf (20.00 KB, text/plain)
2004-12-14 13:41 EST, James Bourne
no flags Details
send function rename (2.90 KB, patch)
2004-12-15 10:11 EST, James Bourne
no flags Details | Diff

  None (edit)
Description James Bourne 2004-12-14 13:36:08 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.3)
Gecko/20040924

Description of problem:
If crond runs a shell script (using any shell and as any user) and the
shell script calls /bin/mail while nscd is not running (ldap is used
here for auth and user lookup) /bin/mail will segfault.  Delivery by
command line is still OK (environment issue?).


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

How reproducible:
Always

Steps to Reproduce:
1. Setup host to authenticate and perform user lookups via LDAP with
ssl start_tls and to cache requests using auth_config
2. setup a cron job that executes the attached script (calls /bin/mail)
3. stop nscd
4. run cron job again and /bin/mail will segfault.
5. start nscd
6. script will run properly
7. repeat steps 3 to 6 until unamused.
    

Actual Results:  /bin/mail segfaults.  Setting ulimit -c unlimited in
the script before the call to /bin/mail will cause a core dump.

Expected Results:  /bin/mail does not segfault but instead actually
sends mail...

Additional info:

This could be within /bin/mail but somehow I don't think that it is,
the circumstances are far too specific to be a /bin/mail problem. 
Also, you can run this from the command line and it will NOT segfault.
 This causes data that should explictly be sent to a person to not be,
then at that point data is lost.

This script is as simple as
#!/bin/bash
ulimit -c unlimited
echo "This is a test" > tmp.msg
/bin/mail -s "Testing" youremail@yourdomain.tld < tmp.msg
rm -f tmp.msg

Run this script from cron with the appropriate LDAP settings as above.  

Attached are the back trace from a core dump from RHEL 2.1 AS, RHEL 3
WS, and our /etc/ldap.conf.
Comment 1 James Bourne 2004-12-14 13:41:58 EST
Created attachment 108548 [details]
contains 3 backtraces and an ldap.conf
Comment 2 Jakub Jelinek 2004-12-15 08:00:00 EST
This looks like /bin/mail's fault.
It exports send (and flock) routines from its dynamic symbol table, but send
in /bin/mail has nothing to do with
http://www.opengroup.org/onlinepubs/009695399/functions/send.html
that libresolv.so uses, so it either crashes, or if you are lucky, just doesn't
work as it should.
Comment 3 James Bourne 2004-12-15 10:11:03 EST
Created attachment 108616 [details]
send function rename

This patch renames the send() function in send.c (and calls to it) to
mailx_send.  I've confirmed that this does fix the problem we're seeing.  My
testing only included running the test script from cron with and without nscd
running.  Also, dropped back to the original mailx and the problem reoccured as
expected.
Comment 5 James Bourne 2004-12-15 12:10:41 EST
Is this a duplicate then of
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=134837

Comment 9 Jindrich Novy 2005-03-03 09:48:43 EST
Patch for this is added to CVS since Feb 18th, changing status -> MODIFIED.
Comment 12 Ivana Varekova 2007-07-23 08:44:46 EDT
This does not meet the requirements for RHEL 2.1, which is currently in
maintenance mode; as such, this won't be fixed for 2.1.

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