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