Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 23 Nov 1996 15:50:12 -0700
From:      Warner Losh <imp@village.org>
To:        Marc Slemko <marcs@znep.com>
Cc:        Mark Newton <newton@communica.com.au>, freebsd-hackers@freebsd.org
Subject:   Re: non-root users binding to ports < 1024 (was: Re: BoS: Exploit for sendmail smtpd bug (ver. 8.7-8.8.2).) 
Message-ID:  <E0vRQto-0003kX-00@rover.village.org>
In-Reply-To: Your message of "Sat, 23 Nov 1996 15:33:46 MST." <Pine.BSF.3.95.961123150746.5433B-100000@alive.ampr.ab.ca> 
References:  <Pine.BSF.3.95.961123150746.5433B-100000@alive.ampr.ab.ca>  

next in thread | previous in thread | raw e-mail | index | archive | help
In message <Pine.BSF.3.95.961123150746.5433B-100000@alive.ampr.ab.ca>
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E0vRQto-0003kX-00>