<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Till,<div class=""><br class=""><blockquote type="cite" class="">On Jun 14, 2016, at 6:53 PM, Till Kamppeter <<a href="mailto:till.kamppeter@canonical.com" class="">till.kamppeter@canonical.com</a>> wrote:<br class=""><br class="">Hi,<br class=""><br class="">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<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>- Interface scripts are no longer supported for security reasons<br class=""><span class="Apple-tab-span" style="white-space:pre"> </span> (<<a href="rdar://problem/23135640" class="">rdar://problem/23135640</a>>)<br class=""></blockquote><div class=""><br class=""></div><div class="">Here is the original text from this (internal) bug report:</div><div class=""><br class=""></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">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.</div><div class=""><br class=""></div><div class="">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).</div><div class=""><br class=""></div><div class="">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.</div></blockquote><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">System V interface scripts give a possibility to create filtered print queues without PPD.<br class=""><br class="">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).<br class=""><br class="">By the way, PPD files are also on the way to get deprecated.<br class=""></blockquote><div class=""><br class=""></div>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...)</div><div class=""><br class=""><blockquote type="cite" class="">Now I have some questions about what to do:<br class=""><br class="">- How will I do non-raw (filtered) queues without PPD files?<br class=""></blockquote><div class=""><br class=""></div>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.</div><div class=""><br class=""></div><div class="">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...</div><div class=""><br class=""></div><div class="">(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...)</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class="">- Or should cups-browsed always generate PPD files, using certain<br class=""> default values for capability info which it is not able to obtain<br class=""> from the printer?<br class=""></blockquote><div class=""><br class=""></div>This would also work.</div><div class=""><br class=""><blockquote type="cite" class="">- What were the security reasons leading to remove the interface script<br class=""> support from CUPS? It seems that this got only discussed internally<br class=""> at Apple.<br class=""></blockquote><div class=""><br class=""></div>See above.</div><div class=""><br class=""><blockquote type="cite" class="">- And if there are neither interface scripts nor PPD files (probably<br class=""> this requires all printers being IPP Everywhere), how will CUPS<br class=""> determine which filters to run?<br class=""></blockquote><div class=""><br class=""></div>That isn't something that is being considered in CUPS for at least a few years yet...</div><div class=""><br class=""></div><div class=""><div class="">_________________________________________________________<br class="">Michael Sweet, Senior Printing System Engineer<br class=""></div><br class=""></div></body></html>