From owner-freebsd-hackers Sat Nov 23 14:50:53 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id OAA16919 for hackers-outgoing; Sat, 23 Nov 1996 14:50:53 -0800 (PST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id OAA16913 for ; Sat, 23 Nov 1996 14:50:46 -0800 (PST) Received: from rover.village.org [127.0.0.1] by rover.village.org with esmtp (Exim 0.56 #1) id E0vRQto-0003kX-00; Sat, 23 Nov 1996 15:50:12 -0700 To: Marc Slemko Subject: Re: non-root users binding to ports < 1024 (was: Re: BoS: Exploit for sendmail smtpd bug (ver. 8.7-8.8.2).) Cc: Mark Newton , freebsd-hackers@freebsd.org In-reply-to: Your message of "Sat, 23 Nov 1996 15:33:46 MST." References: Date: Sat, 23 Nov 1996 15:50:12 -0700 From: Warner Losh Message-Id: Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk In message Marc Slemko writes: : I want to try to keep the very political and religious issue of running : sendmail as a non-root user out of the discussion of non-root users : binding to ports <1024 as much as possible because the sendmail issue : isn't something that can be solved easily. : : I see little room for bugs in the kernel implementation of non-root users : binding to ports <1024; there is lots of room for problems in the use of : such a feature by programs, but that is really a different issue; : probably more important, but different and far more involved. True. I a trivial way to do this would be for programs that wish to bind to a port < 1024 would be as follows. Consider inetd. Now, let's say there is another such program that creates a listening socket, forks, setuid to something, execs a server program (say sendmail). This server program can then have access to that port w/o running as root. No need for the kernel to get involved at all. When the server wishes to close the port, he does so. Then, when the server wants to reopen it, that server would just exit. The controlling program would then refork, etc and then the server would be back in business. While all servers that wish to bind to ports < 1024 and not run as root would have to be configured in a central file, this accomplishes most things that the kernel interface talked about would do. Heck, you could even merge this functionality into inetd, or have a new program, inetd2 for lack of a better name, do it. Maybe I've missed something here... I don't see a compelling need for this facility in the kernel, at least for the most common cases that I've seen examples for. I can imagine complex programs desiring some way to bind mutliple ports, or not have to exit to get back into the swing of things. I'll leave the design issues of sendmail alone as well :-).... Warner