[Printing-architecture] [cups] CUPS 2.2.x drops interface scripts - How to create filtered queues without PPD
msweet at apple.com
Wed Jun 15 03:00:56 UTC 2016
> On Jun 14, 2016, at 6:53 PM, Till Kamppeter <till.kamppeter at canonical.com> wrote:
> I have seen now the new features list of the first beta of the CUPS 2.2.x series and one of the changes is
> - Interface scripts are no longer supported for security reasons
Here is the original text from this (internal) bug report:
When a user adds a printer through the Web interface, it's possible to select a predefined model or to upload its own PPD (PostScript Printer Description) file, which is a file format created by vendors to describe the entire set of features and capabilities available for their printers. These files contain the PostScript code (commands) used to invoke features for the print job and hence, they have a preformated structure and known keywords.
CUPS doesn't check if the uploaded file is a valid PPD file, and therefore, it simply copies the file into the /etc/cups/interaces/ folder with 755 permissions (World executable).
As it could be seen, it was possible to upload a PDF, a txt and even an ELF executable into that directory through the Web interface. See attachment.
> System V interface scripts give a possibility to create filtered print queues without PPD.
> I make use of this in cups-filters. If cups-browsed discovers an IPP network printer (with "CreateIPPPrinterQueues Yes" in cups-browsed.conf) and is not able to gather enough info via IPP for making a PPD for this printer, it creates a queue with interface script, the script calling the filter sys5ippprinter which in turn calls all filters to convert the input format (PDF, JPEG, or PWG Raster) into the printer's native format (PWG Raster, PDF, PostScript, PCL-XL, or PCL 5c/e).
> By the way, PPD files are also on the way to get deprecated.
Yeah, and have been since CUPS 1.4 (7 years ago...) Even the current IPP Everywhere local printer support in CUPS still uses PPDs internally - we want to move off PPDs, but doing so will require a concerted effort and proper printer support (almost there...)
> Now I have some questions about what to do:
> - How will I do non-raw (filtered) queues without PPD files?
You don't, and can't. There is no way to safely support interface scripts, and they don't work like regular print queues anyways (on OS X they won't even show up in the Print dialog because there is no PPD), so interface scripts are gone for good.
What you *can* do in 2.2 (and before) is use a PPD file to point to an interface script (which acts as the printer/PPD filter) that was previously installed locally by the root user and has the correct permissions (owned by root, no world or group write permissions) for us to minimally trust the script. That has the happy side effect of exposing common options for media, etc. to regular applications that otherwise would be unable to use the queue...
(I fully realize we are passing the security bug to the OS guys, but it seems safer than allowing arbitrary code to be uploaded through cupsd as an interface script that we run directly...)
> - Or should cups-browsed always generate PPD files, using certain
> default values for capability info which it is not able to obtain
> from the printer?
This would also work.
> - What were the security reasons leading to remove the interface script
> support from CUPS? It seems that this got only discussed internally
> at Apple.
> - And if there are neither interface scripts nor PPD files (probably
> this requires all printers being IPP Everywhere), how will CUPS
> determine which filters to run?
That isn't something that is being considered in CUPS for at least a few years yet...
Michael Sweet, Senior Printing System Engineer
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Printing-architecture