From owner-freebsd-stable Thu Sep 16 14:32: 1 1999 Delivered-To: freebsd-stable@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 54282157DA for ; Thu, 16 Sep 1999 14:31:48 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <40342>; Fri, 17 Sep 1999 07:29:29 +1000 Date: Fri, 17 Sep 1999 07:31:41 +1000 From: Peter Jeremy Subject: Re: mail.local setuid To: stable@FreeBSD.ORG Cc: anton@urc.ac.ru Message-Id: <99Sep17.072929est.40342@border.alcanet.com.au> Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Yesterday, I wrote: > A newer approach is to run sendmail as a non-privileged user and/or > in a sandbox, relying on separate, smaller, easily audited programs > to manage the port binding and mail delivery. Having looked into this further (after a followup message), it seems I stretched reality slightly here. I thought sendmail had a facility to run as a daemon on a socket passed into it (ie stdin or stdout). (Which would allow a trivial root program to create a socket, bind it to port 25, drop root and exec sendmail). It turns out that sendmail only has the ability to handle a single SMTP exchange via stdin/stdout - which allows it to be run from inetd. (But this mode has a variety of performance-related disadvantages). Sendmail _does_ have a built-in `run-as-user/group' facility, but there's a significant amount of code (including the sendmail.cf processing) that still runs as root. Sorry for any confusion. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message