Re: Retiring lpr and lpd

"Enji Cooper (yaneurabeya)" <[email protected]> Fri, 20 Feb 2026 16:10:50 -0800

Newsgroups	gmane.os.freebsd.architechture
Message-ID	<[email protected]>

> 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?

I’m not a fan of lpd either for the reasons you cite, but just like running nfsv3, security’s a bit “Wild West” compared to what it used to be like back in the day and it’s reflected in some software like this (as well as rsh, etc). Nuking lpr from the tree seems a bit non-ideal though as it’s still somewhat functional.

Thanks,
-Enji

PS This is coming from someone who wrote a hacky appliance back in the day that leveraged lpr — it would have been a mess with cups.

signature.asc (application/pgp-signature, 833 B)