jim@mcvax.UUCP (Jim McKie) (10/27/83)
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!jimdmmartindale@watcgl.UUCP (Dave Martindale) (10/27/83)
From looking at mail from ucbvax, it would appear that their internal mail delivery software, and perhaps uucp itself, runs as "daemon". Perhaps this is an undocumented assumption of their /bin/mail.