[cups] Searching recursively for backends and filtes inside ServerBin directory?

[Mario Sanchez Prada]

Hi Michael,

Thanks for your quick reply, very helpful indeed. See a few comments
inline below...

On Wed, Oct 15, 2014 at 7:55 PM, Michael Sweet <msweet at apple.com> wrote:
>[...]
> While we might consider such a thing for filters, in general it is unnecessary
> since the path to "driver" filters can be specified in the PPD file.  All that
> CUPS requires is that such filters be installed by root without world write
> permissions...
>
Yes, I saw in the documentation that it is possible to do this using
the "Filter application/vnd.cups-*" directive, and modifyind/adapting
the PPD files would probably be an option for us, as we will probably
have to repackage those drivers anyway to fit our dir structure. And
we still could do certainly do that, so we can keep our installation
as close to the standard as possible, but still we have problems with
the files under backend/, and potentially under driver/ too (see
below).

> As for backends, we really only want to use trusted programs as backends,
> and supporting a path-like mechanism could introduce security and long-term
> deployment issues since which backend is used could vary in
> hard-to-discover/manage ways.

That's a good point, and something I did not consider yet. Thanks for
pointing it out.

> Moreover, backends tend to support common interfaces/transports and are not
> generally included as part of a driver.

Well, I did found a couple of cases where they are indeed included as
part of the drivers, like the Canon InkJet drivers cnijfilter2 and
cnijfilter-common, which install the following CUPS backends:
   cnijfilter2: /usr/lib/cups/backend/cnijbe2
   cnijfilter-common: /usr/lib/cups/backend/cnijbe
   cnijfilter-common: /usr/bin/cnijnetprn
   cnijfilter-common: /usr/lib/cups/backend/cnijnet
   cnijfilter-common: /usr/lib/cups/backend/cnijusb

(See https://launchpad.net/~michael-gruz/+archive/ubuntu/canon/+packages)

And there's yet another type of executables (that I forgot to mention
in my previous email) that are sometimes provided by specific printer
drivers too: the driver programs under /usr/lib/cups/driver. For
instance, you can check the printer-driver-escpr from Debian/Ubuntu in
http://packages.ubuntu.com/trusty/printer-driver-escpr, which installs
the following files in the system:

  /usr/lib/cups/driver/escpr
  /usr/lib/cups/filter/epson-escpr-wrapper
  /usr/lib/cups/filter/epson-escpr

Or printer-driver-dymo:

  /usr/lib/cups/driver/dymo
  /usr/lib/cups/filter/raster2dymolw
  /usr/lib/cups/filter/raster2dymolm

However, in this case I guess what we would need to do would be (1) to
uncompress the base64 compressed list of PPDs, (2) update the path of
the Filter to point to our desired location, (3) compress it again and
(4) update the driver program with the result. Is that correct?

So, all in all it seems that the critical thing is to find a way to
deal with additional driver backends living outside of
/usr/lib/cups/backend, as filters and driver programs in /usr/lib/cups
can be easily "fixed" by updating the paths in the PPD files. Assuming
we find a secure way to do that in our -fairly controlled- system,
would you see any missing piece in the puzzle? Or even better, do you
think there could be a way to find such a controlled way to implement
this upstream (extending the search path for bakends)?

Thanks a lot for your valuable feedback,
Mario