On Ubuntu, both. A system daemon with interesting interactions with avahi-daemon and colord, and a somewhat sandboxed user program, just so Chrome is not overly inconvenienced by its snap sandboxing. But wait, there is more: The login & lock screen also runs the whole glory of GNOME.. to query printer settings. So you can have those sweet, sweet "new printer" notifications overlaid while inputting your password. Or whatever else "your" printer needs to add there.

FWIW, on OpenBSD, cups-browsed is not on my system, but there are some cups files.

But cups-browsed is installed when you install packages "net/avahi" and "print/libppd" which I do not know what either of them are.

So I guess on Linux avahi needs cups-browsed.

It's a spooler for a printing system that supports concurrent job submission, potentially among multiple users. It's going to have to achieve serialization some kind of way.

Why does it need to run as `root` user and not `cups`?

As long as that user can talk to the printers' device nodes (and/or the network), it needn't so far as I know.

The original "system daemon vs. user program" dichotomy offers a much broader range of interpretations than this, though, and it was more the implication of "this can and should be an evanescent program invoked by individual users, implicitly persisting little or no state between invocations" to which I sought to object.

(That said, I take another nearby commenter's point regarding the need, and existence, of a more evanescent and safer option on systems that will never see more printing than one user does two or three times a year.)

Binding to ports under 1024 traditionally requires root privileges. (These days of course that isn't quite as true as it used to be.)

It's common practice to open the socket to start listening on the <1024 port, then drop the root privileges and continue as a different user.

On a modern Linux system, it’s better to use the CAP_NET_BIND_SERVICE capability instead. Then you don’t need to start the process as root at all.

Why on Earth do ordinary systems need CUPS binding to a port at all?

They don't. cups-browsed is a legacy component that isn't needed on ordinary systems, which outsource printer discovery to an mDNS service such as avahi.

They don't need. Want, for listening to network printers announcing themselves. It's a very bad system, even then.

Have you ever seen a network printer announce itself by talking to a print daemon on port 631?

I’ve seen network printers announce themselves over DNS-SD/mDNS and over NetBIOS, AppleTalk, etc. All of those are a layer beneath the print daemon.

I believe these vulnerabilities only allow RCE as the 'lp' user (which is able to access parallel ports and USB devices that identify themselves as printers). In addition the process will be confined by MAC policies (e.g., on Fedora/Red Hat I think they're confined by cupsd_t).

I have never, in the entire history of my usage of desktop systems, wanted my system to spool out a print job on behalf of a non-current user. Nor have I wanted my system to continue servicing my print queue after I log out. To the contrary: it’s incredibly annoying when the queue glitches out and then my print jobs show up in the printer tray after I’ve left.

On multi-user systems (accessed simultaneously by multiple interactive accounts), sure, I’ve once worked in a lab where multiplexing a printer would make sense. Make this a non-default option, please. And have a printer multiplexing daemon, not an entire shared monstrosity like CUPS.

On terminal-server style systems, the print system should be per user, because the printers are per user. I don’t want to print to a printer wherever the terminal server lives — I want to print to the printer near me.

I once ran an actual print server for a couple years. It did accounting, correctly, by wiring CUPS to a little program I wrote that actually spoke PJL correctly. CUPS, of course, can’t actually do this.

This is the worry. It seems like a really unnecessary privilege escalation.

It's because of the frankly idiotic idea of persistent print queues. If you want to have this artifact that survives a user session, then the print subsystem needs super-user abilities.

ChromeOS does away with the whole idea. There are no persistent printer queues or jobs. Artifacts of the printing subsystem have lifetime tied to the user session.

No, persistent print queues can be implemented without cups running as super-user.

I'm a little confused why this is even an issue. Persistent queues have been an option since the days of Windows 9x.

Maybe it's a Gnome problem. KDE let's me see what I had previously printed if I want to see it, or reprint something.

I also know many people in pre-press who make good use of that.

Windows 9x printing was every bit as bad as CUPS.

The point was about the retention of print jobs in queue, that it was a concept and option since the mid 90s.