[comp.mail.sendmail] inappropriate checks when mailing to a file

e07@nikhefh.nikhef.nl (Eric Wassenaar) (05/14/91)

When sending to a file, sendmail checks whether it may succeed
in module recipient() by calling writable() to see if an existing
file is writable or by calling safefile() to see if the parent
directory is writable if the file does not yet exist.
However, these tests use sendmail's current getruid(), whereas
the actual delivery to the file should be performed with the
uid/gid of the controlling address. Therefore, the tests will
fail in many cases and the mail will not be delivered.
I think these tests are premature at this moment, and should be
postponed until the actual delivery takes place in module mailfile()
which already takes care of all necessary precautions for proper
delivery. The correct uid/gid are available at that time, also
during queue runs since they have been restored by the "controlling
user" feature.
Therefore, in my opinion the writable()/safefile() tests can be
eliminated from recipient() altogether. Is this observation correct ?

Eric Wassenaar
-- 
Organization: NIKHEF-H, National Institute for Nuclear and High-Energy Physics
Address: Kruislaan 409, P.O. Box 41882, 1009 DB Amsterdam, the Netherlands
Phone: +31 20 592 0412, Home: +31 20 6909449, Telefax: +31 20 592 5155
Internet: e07@nikhef.nl

rickert@mp.cs.niu.edu (Neil Rickert) (05/14/91)

In article <1232@nikhefh.nikhef.nl> e07@nikhefh.nikhef.nl (Eric Wassenaar) writes:
>When sending to a file, sendmail checks whether it may succeed
>in module recipient() by calling writable() to see if an existing
>file is writable or by calling safefile() to see if the parent
>...
>Therefore, in my opinion the writable()/safefile() tests can be
>eliminated from recipient() altogether. Is this observation correct ?

 You have probably rediscovered why many people prefer to use

 "|/bin/cat >> /path/to/file"
rather than
 /path/to/file

At least in recent versions of sendmail there is another option.  Simply
do:  chmod 4600 /path/to/file
and since the 'suid' bit is on, but no 'x' bit is on, sendmail uses the
uid of the file owner.

 Apart from that, you are probably right.  The tests in recipient.c are
perhaps too paranoid.

-- 
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  Neil W. Rickert, Computer Science               <rickert@cs.niu.edu>
  Northern Illinois Univ.
  DeKalb, IL 60115                                   +1-815-753-6940

mrl@uai.com (Mark R. Ludwig) (05/16/91)

In article <1991May14.044620.18159@mp.cs.niu.edu> Neil Rickert writes:
>At least in recent versions of sendmail there is another option.  Simply
>do:  chmod 4600 /path/to/file
>and since the 'suid' bit is on, but no 'x' bit is on, sendmail uses the
>uid of the file owner.

Having no access to sendmail sources, I have to ask: what does it mean
to use the uid of the file owner if the file isn't executable?  Do you
mean that sendmail changes to that uid before trying to deliver the
mail into the file?  If sendmail is root in the first place, I don't
see the benefit.$$
-- 
INET: mrl@uai.com       UUCP: uunet!uaisun4!mrl       PSTN: +1 213 822 4422
USPS: 7740 West Manchester Boulevard, Suite 208, Playa del Rey, CA  90293
WANT: Succinct, insightful statement to occupy this space.  Inquire within.

rickert@mp.cs.niu.edu (Neil Rickert) (05/16/91)

In article <1991May15.220551.4472@uai.com> mrl@uai.com (Mark R. Ludwig) writes:
>Having no access to sendmail sources, I have to ask: what does it mean
>to use the uid of the file owner if the file isn't executable?  Do you
>mean that sendmail changes to that uid before trying to deliver the
>mail into the file?  If sendmail is root in the first place, I don't
>see the benefit.$$

  That is exactly what it means.  For delivery to such a file, sendmail
changes uid to the file's owner before attempting do deliver to the file.

  With your comment "I don't see the benefit" I presume you point is that
as root, it can automatically deliver.  That is true.  But there may be
reasons which would prevent the owner from writing to that file, and
sendmail should observe those.  For example the system might support some
weird form of file locking which root would automatically override.
For a specific case, root can override disk quotas, but the file owner
cannot.  Changing to the file owner is just good programming.

-- 
=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
  Neil W. Rickert, Computer Science               <rickert@cs.niu.edu>
  Northern Illinois Univ.
  DeKalb, IL 60115                                   +1-815-753-6940

karl.kleinpaste@osc.edu (05/16/91)

mrl@uai.com writes:
   Do you
   mean that sendmail changes to that uid before trying to deliver the
   mail into the file?  If sendmail is root in the first place, I don't
   see the benefit.

If the destination file is on an NFS-mounted filesystem with
root->nobody across the wire, it matters.

kre@cs.mu.oz.au (Robert Elz) (05/22/91)

rickert@mp.cs.niu.edu (Neil Rickert) writes:

>With your comment "I don't see the benefit" I presume you point is that
>as root, it can automatically deliver.  That is true.

Is it really?   I think you'll find that if the setuid bit isn't set
on the file, then sendmail changes to either the user ID of the user
who sent the mail (for local mail) or its default user ID (often daemon)
to access the file.

In practice, a file needs to be setuid, or 666 mode, to work as
a destination for mail.  It can't have execute permission (sendmail
won't write to it if it does), so the setuid is harmless.

kre