Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83 (MC830919); site mcvax.UUCP
Path: utzoo!linus!philabs!mcvax!jim
From: jim@mcvax.UUCP (Jim McKie)
Newsgroups: net.bugs.4bsd,net.mail
Subject: 4.2BSD mail bug
Message-ID: <5447@mcvax.UUCP>
Date: Wed, 26-Oct-83 18:22:06 EDT
Article-I.D.: mcvax.5447
Posted: Wed Oct 26 18:22:06 1983
Date-Received: Thu, 27-Oct-83 04:18:03 EDT
Organization: Math.Centre, Amsterdam
Lines: 29

Well, I thought it was a bit quiet. Then I discovered that all
mail destined from the outside world to someone on my machine
was silently being thrown away by /bin/mail!

Between the pre-release of 4.2BSD and the final release, a security
hole in /bin/mail was closed, a check was put in such that only
the users "root", "daemon" and "network" were allowed to use the 
"-r name" option, which specifies that the name of the person who
sent this mail is "name", and not what you can get out of /etc/passwd
using the result of getuid(). This is used by /usr/lib/sendmail to
give you sensible names as the originator of remote mail.

Unfortunately, the sendmail documentation is misleading, implying that
it will do a setuid() to the default uid (usually daemon) before
exec'ing any mailer, such as /bin/mail to do local delivery. This is
not so, the setuid() will only be done if the real uid of sendmail is
"root", i.e. it is running as a daemon, not when it is running as the
result of being called by "rmail", when the real uid is probably that
of "uucp". So /bin/mail says "sorry, no permission", but still gives
0 exit status, and sendmail logs the mail away as being successfully
delivered.

The fix is to either remove the tests on "root", "daemon" and "network",
leaving the security hole, or to add "uucp" to the list. This latter may
not always work, however, if you have people calling you up whose uid in
the password file is not the same as the user "uucp". There may be other
solutions.

Jim McKie  Mathematisch Centrum, Amsterdam  ..{decvax!philabs}!mcvax!jim