Re: Retiring lpr and lpd
Steve Kargl <[email protected]> Fri, 20 Feb 2026 20:14:15 -0800
| Newsgroups | gmane.os.freebsd.architechture |
|---|---|
| Message-ID | <[email protected]> |
On 2/20/26 16:10, Enji Cooper (yaneurabeya) wrote: > >> On Feb 20, 2026, at 10:40 AM, Dag-Erling Smørgrav <[email protected]> wrote: >> >> Hi, >> >> The lp* family of printing utilities have received practically no >> maintenance in two decades and are showing their age. What's worse, >> most of them are setugid, and lpd(8) is a network-facing daemon with >> IP-based authentication and little to no input validation. Furthermore, >> better-maintained alternatives are available from ports: print/lprng is >> a drop-in replacement derived from the same code base, while print/cups >> provides far more functionality and a compatible command-line interface. >> >> Unless someone steps up and does a credible job of modernizing these >> utilities, we have no other choice than to retire lp(1), lpc(8), lpd(8), >> lpq(1), lpr(1), lprm(1), lptest(1), and pac(8) from base. >> >> In the next few days, I will commit patches to add deprecation notices >> to all relevant manual pages (D55381) and switch the LPR build option >> from default-on to default-off (D55380). The code will remain in the >> tree, and remain buildable, but unless the situation changes, it will be >> removed from the tree no later than shortly before stable/16 is branched >> in the fall of 2027. > > How hard would it be to remove the set*uid bit and just require the process be run as a non-root user/the cdevs be writable to a printer group using devfs rules and devd? With a very quick scan, it looks like openbsd addressed the problem 24 years ago. https://cvsweb.openbsd.org/src/usr.sbin/lpr/lpd/recvjob.c?rev=1.21&ipk=vLq3KLbJEp-19gMBaNEGXf_4MUcA842PpU-tt76KwVI&content-type=text/x-cvsweb-markup PS: the signed integer overflow that das@ may still be present in openbsd. -- steve