openprinting / cups-browsed Goto Github PK

I reported an issue in the GNOME/GTK forums related to a serious basic network printing problem involving CUPS, where printing from any GTK application would result in overriding of user-specified print settings (either the system settings would silently override the user-specified settings—like duplex-vs-simplex or color-vs-monochrome printing—or other unexpected and seemingly random things would occur, like printing on massive-sized paper when that is not specified anywhere).

I tracked it down to be related to implicitclasses in the CUPS protocol.

Could you please work with the GTK people to resolve this issue (or else help to determine if it just needs to be addressed on one side vs the other)? I've tried disabling ImplicitClasses in cupsd.conf, but it doesn't seem to help.

Here is the issue as I reported it in GNOME GitLab: https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/2463

Thank you in advance. It is a serious problem for network printing and does not help in efforts to make Enterprise Linux Desktop viable and reputable.

I have to restart the cups-browsed.service pretty often when my printer gets set to inactive after some suspend/resume cycles. I'm not sure if this maybe printer model related (Samsung M2825DW via IPPeverwhere). If have this on my desktop as well when trying to access from laptop using the same OS.

Attaching debug cups-browsed logs where the printer failed trying to print after the 19:59 resume:
cups-browsed_log.before_restart.txt
cups-browsed_log.after_restart.txt

Any idea how to track this down and if this could be an issue in cups-browsed or the printer firmware? Could this also be some issue in cups itself?

This is Arch Linux running cups-browsed 2.0.0-2 (last master commit added) and cups 2.4.8-1.

Writing into string p using formatted input function at cups-browsed.c:5476 may lead to a buffer overflow, because string conversion specification doesn't have a width limitation.

https://github.com/OpenPrinting/cups-filters/blob/d72184e725591f10e2b404b36fe3bf5bc304a299/utils/cups-browsed.c#L5476

It is possible that the variable p at function fscanf(fp, "%s", p), which is defined as a pointer to the variable buf[1024] at cups-browsed.c:5475, of a very large length can lead to buffer overflow, since the pointer to the fp stream has a length of 2048 defined at cups-browsed.c:500.

Path for fp stream:

https://github.com/OpenPrinting/cups-filters/blob/d72184e725591f10e2b404b36fe3bf5bc304a299/utils/cups-browsed.c#L5469

https://github.com/OpenPrinting/cups-filters/blob/d72184e725591f10e2b404b36fe3bf5bc304a299/utils/cups-browsed.c#L5463

https://github.com/OpenPrinting/cups-filters/blob/d72184e725591f10e2b404b36fe3bf5bc304a299/utils/cups-browsed.c#L500

So there is no guarantee that the length of the variable p obtained from the file does not exceed a length of 1024.

This situation can be resolved by limiting the field width fscanf(fp, "%1024s", p);.

Found by Linux Verification Center (portal.linuxtesting.ru) with SVACE.
Author A. Slepykh.

Hello,

On linux clients when the same printer is defined through different uris ( like ipps://... vs ipp:// ) a check is made in order to verify whether the printer supports the requested job attributes (supports_job_attributes_requested in cups-browsed.c). But there is a problem because human readable values are compared to internal ones. Example: SinglePortrait vs staple-top-left. I'm not sure which one should be remapped before comparison...

Describe the bug
After upgrading to Ubuntu 23.04, my laptop failed to discover our print server.
The problem seems to have been caused by a new change in cups-browsed that was added to Ubuntu 23.04.
I looked into it and found a small fix that seems to solve my issue.

Using the debug configuration for cupsd and cups-browsed, I looked through the logs and noticed the following line:
failed to bind CUPS Browsing socket: Permission denied

After reading more about printer advertisement and cups-browsed, I concluded that the printer is shared to my Ubuntu 23.04 laptop via CUPS on port 631.
When I connected an Ubuntu 22.04 laptop to the WIFI network, I saw the printer really was being shared with CUPS on port 631.
Cups-browsed was running as root on 22.04 while on 23.04 it is running as a new user - cups-browsed, but this new user didn't seem to have the necessary permissions to open a listening socket on port 631.
The solution I tried was granting the relevant binding permissions to the binary with this command (on the 23.04):
setcap cap_net_bind_service+ep /usr/sbin/cups-browsed

After giving the permissions, my computer successfully discovered the printer, just like it used to on 22.04!
I think the command should be added to the post install script or maybe the capability should be granted to the new cups-browsed user.

OS: Debian buster
CUPS Version: 2.2.10

Hi, please understand that I'm not a native speaker.

I think the code below should be deleted.
https://github.com/OpenPrinting/cups-filters/blob/7999624bd2d2e3297c44f88d7070f6f44f6db31d/utils/cups-browsed.c#L8606-L8608

Because,

1. the printer-location option is loaded to p->options at
   https://github.com/OpenPrinting/cups-filters/blob/7999624bd2d2e3297c44f88d7070f6f44f6db31d/utils/cups-browsed.c#L8279-L8281
2. after that, p->options is copied to options at line 8622 ~ 8627 and encoded to IPP request at line 8628 ~ 8630.
   https://github.com/OpenPrinting/cups-filters/blob/7999624bd2d2e3297c44f88d7070f6f44f6db31d/utils/cups-browsed.c#L8622-L8630

But, If the printer-location option was added to IPP request in advance like line 8606 ~ 8608,
the printer-location option is ignored at the cupsEncodeOptions2 fuction(line 8628 ~ 8630)
because it is in IPP request already.

As a result, after reboot, the printer-location value in /var/cache/cups/cups-browsed-options-* is became empty
because, from what I've seen so far, the p->location is always empty string.

(and I also think this should be deleted too, because of needless
https://github.com/OpenPrinting/cups-filters/blob/7999624bd2d2e3297c44f88d7070f6f44f6db31d/utils/cups-browsed.c#L8618-L8620)

My only printer is an old epson inkject which is locally via usb.

According to configure, '--disable-avahi' allows builds without avahi.

** build details **
configure:

Environment settings:
CFLAGS: -g -O2 -Wall -std=gnu11 -D_GNU_SOURCE
CXXFLAGS: -Wall -D_GNU_SOURCE
LDFLAGS:
Build configuration:
cups-config: system
init directory:
cups dom socket: /run/cups/cups.sock
avahi: no
browsing: dnssd cups
local queue naming for remote CUPS queues: DNS-SD
keep generated queues during shutdown: no
update network interfaces after each found entry: yes
all ipp printer auto-setup: yes
only driverless auto-setup: no
only local auto-setup: no
werror: no

'make' then fails with:
gcc -DHAVE_CONFIG_H -I. -I/usr/include/cupsfilters -I/usr/include/ppd -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libmount -I/usr/include/blkid -pthread -I/usr/include/gio-unix-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libmount -I/usr/include/blkid -pthread -g -O2 -Wall -std=gnu11 -D_GNU_SOURCE -MT daemon/cups_browsed-cups-browsed.o -MD -MP -MF daemon/.deps/cups_browsed-cups-browsed.Tpo -c -o daemon/cups_browsed-cups-browsed.o test -f 'daemon/cups-browsed.c' || echo './'daemon/cups-browsed.c
daemon/cups-browsed.c:405:3: error: unknown type name 'AvahiIfIndex'
405 | AvahiIfIndex interface;
| ^~~~~~~~~~~~
daemon/cups-browsed.c:406:3: error: unknown type name 'AvahiProtocol'
406 | AvahiProtocol protocol;
| ^~~~~~~~~~~~~
daemon/cups-browsed.c:411:9: error: unknown type name 'AvahiAddress'
411 | const AvahiAddress *address;
| ^~~~~~~~~~~~
(etc)

Expected behavior
Build succeeds without avahi.

System Information:

• OS: LinuxFromScratch
• Version 20221113

Additional context
Since I lack a networked printer, installing avahi would be an unnecessary vulnerability.

Describe the bug

$ make -j1
gdbus-codegen \
    --interface-prefix org.cups.cupsd \
    --c-namespace Cups \
    --generate-c-code cups-notifier \
    daemon/org.cups.cupsd.Notifier.xml
make  all-recursive
make[1]: Verzeichnis „/home/domain/user/Downloads/cups-browsed-2.0.0“ wird betreten
make[2]: Verzeichnis „/home/domain/user/Downloads/cups-browsed-2.0.0“ wird betreten
  CC       backend/implicitclass-implicitclass.o
  CCLD     implicitclass
  CC       daemon/cups_browsed-cups-browsed.o
daemon/cups-browsed.c:405:3: error: unknown type name 'AvahiIfIndex'
  405 |   AvahiIfIndex interface;
      |   ^~~~~~~~~~~~
daemon/cups-browsed.c:406:3: error: unknown type name 'AvahiProtocol'
  406 |   AvahiProtocol protocol;
      |   ^~~~~~~~~~~~~
daemon/cups-browsed.c:411:9: error: unknown type name 'AvahiAddress'
  411 |   const AvahiAddress *address;
      |         ^~~~~~~~~~~~
daemon/cups-browsed.c:413:3: error: unknown type name 'AvahiStringList'
  413 |   AvahiStringList *txt;
      |   ^~~~~~~~~~~~~~~
daemon/cups-browsed.c:414:3: error: unknown type name 'AvahiLookupResultFlags'
  414 |   AvahiLookupResultFlags flags;
      |   ^~~~~~~~~~~~~~~~~~~~~~
daemon/cups-browsed.c: In function 'get_local_queue_name':
daemon/cups-browsed.c:6196:13: warning: assignment discards 'const' qualifier from pointer target type [-Wdiscarded-qualifiers]
 6196 |         str = resource;
      |             ^
daemon/cups-browsed.c: In function 'examine_discovered_printer_record':
daemon/cups-browsed.c:10199:7: warning: unused variable 'raw_queue' [-Wunused-variable]
10199 |   int raw_queue = 0;
      |       ^~~~~~~~~
daemon/cups-browsed.c: At top level:
daemon/cups-browsed.c:3897:1: warning: 'local_printer_has_uuid' defined but not used [-Wunused-function]
 3897 | local_printer_has_uuid (gpointer key,
      | ^~~~~~~~~~~~~~~~~~~~~~
make[2]: *** [Makefile:1075: daemon/cups_browsed-cups-browsed.o] Fehler 1
make[2]: Verzeichnis „/home/domain/user/Downloads/cups-browsed-2.0.0“ wird verlassen
make[1]: *** [Makefile:1260: all-recursive] Fehler 1
make[1]: Verzeichnis „/home/domain/user/Downloads/cups-browsed-2.0.0“ wird verlassen
make: *** [Makefile:769: all] Fehler 2

To Reproduce
Steps to reproduce the behavior:

1. ./configure --disable-avahi
2. make
3. See error

Expected behavior
Allow to build with avahi support disabled.

Screenshots

System Information:

• OS: Linux
• Version -

Additional context

Is your feature request related to a problem? Please describe.
It doesn't look like this supports MacOS, given how tied it is to avahi?

Describe the solution you'd like
There appears to be no easy way to point MacOS cups to an existing cups server without overwriting client.conf (which naturally breaks local-only printing). Adding MacOS support would fix this.

cups-browsed uses cups-config to find CUPS. It should use pkg-config instead.

Today I cannot print from my Ubuntu 20.10 laptop. The printer is detected, a print job gets created, stays active for 60 seconds, then goes into waiting. /var/log/cups/errorr_log has

E [24/Nov/2021:14:34:36 +0200] [Job 69] Bad value (0) for orientation-requested, using 0 degrees

at the time when the job is first created, then

E [24/Nov/2021:14:35:36 +0200] [Job 69] No destination host name supplied by cups-browsed for printer \"HP_Color_LaserJet_MFP_M477fdw_15A597_\", is cups-browsed running?
W [24/Nov/2021:14:35:36 +0200] [Job 69] Backend returned status 4 (stop printer)

Printing worked fine just a few days ago, with the same Ubuntu version and the same printers. I'm not sure what changed.

OpenPrinting/cups-filters#97 (comment) suggests creating an issue here.

Please check whether at the time of printing cups-browsed is actually running, as cups-browsed tells the job to which destination to go

cups-browsed is running. restarting cups-browsed doesn't make the problem go away.

Which version of cups-filters do you have

1.28.10-2

How many print queues does cups-browsed generate on your system (the ones with implicitclass:/... in the output of lpstat -v).

Two, which is correct: the printer advertises itself over DNS-SD, and there's a local server (fridge.lan) with a CUPS queue for the same printer. Printing to either queue fails in (almost) the same way; the only difference is that only one of the two queues produces the "Bad value (0) for orientation-requested" error.

lpstat -v shows

$ lpstat -v
device for HP_Color_LaserJet_MFP_M477fdw_15A597_: implicitclass://HP_Color_LaserJet_MFP_M477fdw_15A597_/
device for HP_Color_LaserJet_MFP_M477fdw_fridge: implicitclass://HP_Color_LaserJet_MFP_M477fdw_fridge/
device for ML-1640-Series: usb://Samsung/ML-1640%20Series?serial=144QBAAS601512F.

(the USB printer is currently disconnected and is irrelevant to this bug report)

Please create an issue report here with /etc/cups/cupsd.conf and /etc/cups/cups-browsed.conf attached.

• cupsd.conf.txt
• cups-browsed.conf.txt

(I've made two changes to cups-browsed.conf, compared to stock ubuntu config: removed cups from BrowseLocalProtocols, and uncommented DebugLogging file stderr.)

Also, here's /var/log/cups/cups-browsed_log after I enabled debug logging and restarted cups-browsed, then tried printing.

cups-browsed_log.txt

Other bug reports had questions about Avahi version, so

avahi-resolve --version
avahi-resolve 0.8

I can ping both fridge.local and cream.local, i.e. DNS-SD name resolution works fine on the system. (Besides, cups-browserd detects the printers fine, so it must be seeing mDNS packets).

I'm not sure how to interpret the cups-browsed_log. The "Remote printer overview" section is interesting, particularly where it says things like cream.local, IP not determined. The only things logged during the actual print job execution and failure are printer state change notifications that don't seem to be saying anything.

I wish I had debug logging enabled from when printing worked fine, so I could see what differs between now and then...

Describe the bug
Printer queues getting stuck or disabled and sometimes yield a status message "No suitable destination host found by cups-browsed, retrying later" or "No destination host name supplied by cups-browsed for printer , is cups-browsed running?". Printing on other printer queues from cups-browsed works successful, at least most of the time.

We tried solving the problem by clearing all print queues on the affected workstations at first (stopping both daemons and clear printers.conf), but it didn't stop it. The patch 57d9351 from #23 didn't really solved it, too.

At the moment, I suspect a line of shell script in our configuration management (fai) which restarts the cups-browsed daemon after a configuration change.

To Reproduce
Steps to reproduce the behavior:

1. Print a job to a printer queue managed by cups-browsed. Helpful if the print job is bigger than a few pages so you got more time to react.
2. Wait till the program printed and the job is processed by CUPS.
3. Restart the cups or cups-browsed systemd unit. Both should result in some or an other error described above.
4. Printing again to the same queue yields to the same error. Maybe a single print job passes through, but the same error is excepted.

Expected behavior
Printing works even through restart from one of the responsible daemons or the avoidance of persisting the error.

System Information:

• OS: Ubuntu
• Version 22.04 LTS

cups-browsed and cups-filters are backported from Ubuntu mantic (Version 2.0.0-0ubuntu2) because of trouble in earlier versions in junction to our CUPS server on Debian 11.
Also added the patch 57d9351

Additional context
From my current understanding, it's a problem when CUPS want to print but cups-browsed hasn't detected the remote printer. It could be because of those cases:

1. cups-browsed is in restart and therefor, printing isn't possible.
2. CUPS started and have unfinished jobs from the previous run. The daemon tries to print but cups-browsed didn't detected the remote printers yet, so no target to print.

When restarting CUPS, these problematic printing queues persist while other queues appear after cups-browsed detected them. Don't know if thats just a CUPS problem because theres a print job for him also.

On most workstations that reported the problem, we found log messages that systemd killed the service at some time and cups-browsed reports the following message for all print queues at the next start:

Timeout happened during creation of the queue <name>, turn on DebugLogging for more info.

We now tried to temporarily solve this problem by the following systemd unit override for cups.service:

# /etc/systemd/system/cups.service.d/20-cups-jobs.conf
[Service]
ExecStartPre=/usr/bin/find /var/spool/cups -maxdepth 1 -type f -delete

It cleans the printing queue before the start so it wont trigger an undetected cups-browsed printer.
I can give feedback if this solves it. At least at the next restart.

Would be nice if cups-browsed would be more resilient with this.