4 ms·

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

by aftbit 2y ago

stevekemp 2y ago
Binding to ports under 1024 traditionally requires root privileges. (These days of course that isn't quite as true as it used to be.)
- amluto 2y ago
  Why on Earth do ordinary systems need CUPS binding to a port at all?
  - a96 2y ago
    They don't need. Want, for listening to network printers announcing themselves. It's a very bad system, even then.
    - amluto 2y ago
      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.
  - yrro 2y ago
    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.
- ronjakoi 2y ago
  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.
  - cpach 2y ago
    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.
throwanem 2y ago
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.)
yrro 2y ago
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).

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

by aftbit 2y ago

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

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

amluto 2y ago
Why on Earth do ordinary systems need CUPS binding to a port at all?
- a96 2y ago
  They don't need. Want, for listening to network printers announcing themselves. It's a very bad system, even then.
  - amluto 2y ago
    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.
- yrro 2y ago
  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.
ronjakoi 2y ago
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.
- cpach 2y ago
  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.

throwanem 2y ago

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.)

yrro 2y ago

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).