Date: Sat, 22 Sep 2001 01:58:26 -0400 From: Garance A Drosihn <drosih@rpi.edu> To: Cy Schubert <Cy.Schubert@uumail.gov.bc.ca> Cc: freebsd-questions@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: LPD problems in 4.4-STABLE Message-ID: <p05101000b7d1d330a409@[128.113.24.47]> In-Reply-To: <200109182102.f8IL29h65842@cwsys.cwsent.com> References: <200109182102.f8IL29h65842@cwsys.cwsent.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 2:01 PM -0700 9/18/01, Cy Schubert - ITSD Open Systems Group wrote: >Hajimu UMEMOTO writes: > > However, many clients break lpr's traditional scheme. So, new option >> -W was added. From man lpd: >> > > -W By default, the lpd daemon will only accept connections which > > originate from a reserved-port (<1024) on the remote host. The > > -W flag causes lpd to accept connections coming from any port. > >RFC 1179 states that LPD connections should originate from ports 721-731. >I know of only one LPD, MVS TCP/IP Print Services, enforces this. I >think it's fine to have an LPD option or options that allows print to >come from non-standard ports, e.g. < 1024 or any port, however should >LPR/LPD conform to the standard? [I am not quite sure what you are asking. FreeBSD's lpd does conform to the RFC in that it does require a connection from a reserved-port. That may not be "standard" in the sense of "matching the most common implementations of lpr", but it does follow the RFC...] The RFC claims that the only valid ports are 721-731, but freebsd's lpd accepts connections from almost any reserved port. So, we're already a little bit looser than the RFC. I think it is reasonable for us to allow any reserved port [if that is what you are asking...]. There is a good reason to have the requirement of a reserved port. In the RPI environment, we have print servers accepting print jobs from unix machines that we (the computer center) also runs. There are several hundred different students who use those unix workstations. When the print server accepts a job from a unix client, it assumes that the information in the control file is correct. Among other things, this includes the userid of the person sending the job, and we charge that userid based on how many pages the job will print. If the lpd server accepts connections from any port on a client, then a user can just telnet to the lpd port and submit their own control file (which conveniently does NOT charge them...). How could the server possibly tell legitimate control files from bogus ones? I am not much of a slave to the RFC, and I would happily change the protocol if it improves security or reliability. In the case of this change, I think we're better off following the RFC by default, and allowing a way to accept jobs from any port for those people who need it. (really I would like to have that an option which was set on a per-hostname basis, but -W was quick-and-easy to do). >Having said that, all UNIX systems I've worked on, except for AIX, do >not completely adhere to the RFC, hence printing from non-conforming >systems would definitely break. Based on what I have seen over the years, I doubt that there is ANY implementation which strictly and completely follows the RFC... :-) That said, if someone does run into a problem because they have an lpd client which connects from ports > 1024, then they will get an explicit-enough message from freebsd's lpd which will explain the problem to them. At that point they can decide to drop the reserved-port requirement (by adding -W to lpd's startup flags), or instead they might decide to drop the non-conforming lpd on their remote hosts... -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p05101000b7d1d330a409>