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