Date: Sat, 2 Jun 2001 19:19:09 -0700 From: "Morgan Davis" <mdavis@cts.com> To: "'Hajimu UMEMOTO'" <ume@mahoroba.org> Cc: <freebsd-stable@freebsd.org>, <security@freebsd.org>, <wollman@freebsd.org>, <freebsd-print@bostonradio.org>, <drosih@rpi.edu> Subject: RE: Malformed from address Message-ID: <000801c0ebd3$932adae0$271978d8@cts.com> In-Reply-To: <20010603.064924.55505694.ume@mahoroba.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hajimu UMEMOTO writes: > Then, Windows is broken. And, FreeBSD is also seriously outnumbered. > printer client must bind source port to within IPPORT_RESERVED. "Yeah, right." -- Bill Gates :-) I wonder if this imposition was a result of the lpd having a dual role as spooler and server. When lpd runs its spool and connects to a remote print server, you have a server-server arrangement rather than the more common client-server model. Is it right for lpd to force all connections to act as if they were really servers? It may be heretical to state this, but the way that Windows does it, grabbing free ports from the dynamic pool, makes sense in a client-server context. > If you wish to allow such > broken connection, you can simply remove reserved port checking. The restriction in lpd.c breaks printing from the vast majority of computers in this neck of the galaxy. And, there's no fix, other than for each admin to "simply" patch lpd.c, recompile, and deploy throughout their enterprise? I suggest that a compile-time option or a command line flag be added so that the port checking is selectable. (My vote is for a runtime flag that disables port checking or allows you to specify your own acceptable range.) Otherwise, the new behavior will surely impact more people than it serves to protect. While I'm making lpd suggestions, it would be very nice if it were smarter about using syslog or its own -d and -l capabilities to truly log fatal() error messages, rather than spewing them uselessly into stdout (or the socket stream). That doesn't do an administrator any good, until they resort to watching raw packets after hours of troubleshooting their network configuration, client configuration, hosts.lpd file, hosts.equiv file, spool directory permissions, etc., etc. How many have been bit by clients that wouldn't print, only to find that it was because they weren't in hosts.lpd, the client IP addresses changed or a forward/reverse DNS error was introduced, etc? Such a common problem, yet lpd makes it harder than it should be to detect. Garance, what do you think? --Morgan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?000801c0ebd3$932adae0$271978d8>