[comp.mail.sendmail] Bizare problem with sendmail

roy@phri.UUCP (Roy Smith) (01/01/89)

	A week or two ago, mail stopped working on some of our SunOS-3.5.2
systems.  We have 2 mostly identical file servers, with about 8 diskless
clients each.  We run the stock sun sendmail with the "debug" binary patch
on both, but not the sun-supplied sendmail.cf files.  Everything used to
work fine until one server, and the clients it serves, went out to lunch.

	The basic symptoms are as follows:  If you send local mail, the
file in /usr/spool/mail/ ends up being owned by the sender.  If you send
mail that gets delivered over the network (with the faulty machine on the
receiving end) the spool file ends up being owned by deamon.  It looks for
all the world like sendmail has stopped being suid root, but:

wombat> ls -l /usr/lib/sendmail
-r-sr-x--x  1 root       139264 Nov  9 17:03 /usr/lib/sendmail*

which is exactly the same result you get on the other (working) server.
Sum(1) shows the same results for the two /usr/lib/sendmail files and for
the /usr/lib/sendmail.cf files too.  Sun tech support can't figure out
what's going on.  Any ideas?
-- 
Roy Smith, System Administrator
Public Health Research Institute
{allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net
"The connector is the network"

ahl@technix.oz.au (Tony Landells) (01/01/89)

In article <3644@phri.UUCP>, roy@phri.UUCP (Roy Smith) writes:
> 	The basic symptoms are as follows:  If you send local mail, the
> file in /usr/spool/mail/ ends up being owned by the sender.  If you send
> mail that gets delivered over the network (with the faulty machine on the
> receiving end) the spool file ends up being owned by deamon.  It looks for
> all the world like sendmail has stopped being suid root, but:
> 
> wombat> ls -l /usr/lib/sendmail
> -r-sr-x--x  1 root       139264 Nov  9 17:03 /usr/lib/sendmail*

My sun runs SunOS 4.0, so I'm not sure if this is your solution, but
my sendmail will reset its uid to that of the invoker under certain
circumstances (which I'm not too sure of).  Thus, it may be that your
mail program invoking sendmail may have lost its setuid root permission,
causing sendmail to reset its uid to that of the invoker, which would
be the sender for local mail, and daemon for remote mail, wouldn't it?

Tony Landells	<ahl@technix.oz.au>
		<ahl%technix.oz.au@uunet.uu.net>

roy@phri.UUCP (Roy Smith) (01/02/89)

Yesterday, I wrote:
> It looks for all the world like sendmail has stopped being suid root

	Today, not 24 hours later, I got the answer from Per Hedeland
<per@erix.ericsson.se>.  It turns out that local delivery is handled by
/bin/mail, not by /usr/lib/sendmail (yes, I used to know that) and for some
reason, /bin/mail was not suid root.  Considering that mail used to work,
and that it was suid on the twin server, I have to assume that somehow the
suid bit got turned off.  Obviously a case of bit-rot. :-)

	Who needs software support when you've got the net to rely on!
-- 
Roy Smith, System Administrator
Public Health Research Institute
{allegra,philabs,cmcl2,rutgers}!phri!roy -or- phri!roy@uunet.uu.net
"The connector is the network"

jonathan@cs.keele.ac.uk (Jonathan Knight) (01/09/89)

In article <3644@phri.UUCP>, roy@phri.UUCP (Roy Smith) writes:
> 	The basic symptoms are as follows:  If you send local mail, the
> file in /usr/spool/mail/ ends up being owned by the sender.  If you send
> mail that gets delivered over the network (with the faulty machine on the
> receiving end) the spool file ends up being owned by deamon.  It looks for
> all the world like sendmail has stopped being suid root, but:
> wombat> ls -l /usr/lib/sendmail
> -r-sr-x--x  1 root       139264 Nov  9 17:03 /usr/lib/sendmail*

OK, here's my little bit.  Sendmail will reset its uid to the originator
of the mail (which is daemon for networked mail) whenever it invokes the
program to do the next step of the delivery.  For local mail this is /bin/mail
so you need to make sure that this is setuid to root.  As far as I know
sendmail never touches /usr/spool/mail/ at all, it relies on /bin/mail to
do the work.  If you're using a NFS /usr/spool/mail/ then new problems
arise with regard to root access to the disk.  Normally users mailboxes
turn up owned by user 'nobody', to get around this you have to make sure mail
is delivered on the machine which does not have /usr/spool/mail/ as an
NFS mounted partition.

-- 
  ______    JANET :jonathan@uk.ac.keele.cs     Jonathan Knight,
    /       BITNET:jonathan%cs.kl.ac.uk@ukacrl Department of Computer Science
   / _   __ other :jonathan@cs.keele.ac.uk     University of Keele, Keele,
(_/ (_) / / UUCP  :...!ukc!kl-cs!jonathan      Staffordshire.  ST5 5BG.  U.K.