<div dir="ltr">I think that using cupsd as the gateway to all Printer Applications (including IPPUSB) is the best approach.  However, I would like cupsd to be the only application that can communicate with Printer Applications.  It is also convenient if discovery continues to happen using cupsEnumDests and the advertisement protocol shouldn&#39;t be terribly important to client applications.<div><br></div><div>We could perform discovery over a domain socket, even continuing to use DNS-SD if we register the Printer Applications with CUPS.  We could still have ephemeral printers in this case, as CUPS could rediscover the printer but would need some knowledge of which Printer Application is supposed to handle the request.  Since we can only map one uri per domain socket, this would be problematic.  So we would need a dynamic allocation scheme which is potentially complicated.  However, would it be possible to host multiple printers on the same URI distinguishing with some other attribute?  Possibly printer-uuid?  IPP System service specifies a printer-id attribute that can identify printers at a given endpoint.  As far as I can tell, the primary advantage to using TCP over localhost is the presence of port numbers.</div><div><br></div><div>Sean</div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Nov 26, 2018 at 5:47 AM Michael Sweet &lt;<a href="mailto:msweet@apple.com">msweet@apple.com</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Sean,<br>
<br>
The model used by the current release of CUPS is that applications discover printers via DNS-SD and then ask cupsd to communicate with the printer on localhost - we avoid direct network access whenever possible since other OS&#39;s (macOS in particular) use application sandboxing and &quot;entitlements&quot; to limit what an application can do, including creating arbitrary network connections.<br>
<br>
To do the same thing with domain sockets, we&#39;d need to invent yet another backend and discovery mechanism with a dynamic domain socket allocation scheme, have each application (through libcups) communicate with the printer and create a (permanent) print queue with a generated PPD, and then maintain that through the major CUPS architectural changes that are to come.<br>
<br>
I&#39;m not sure if any of this helps you on ChromeOS at all, but personally I think that using cupsd as the gateway to the IPPUSB printer is the better long-term approach (and we&#39;d welcome any bug reports/pull requests if you find instances of the CUPS API talking to a printer directly without the application opening an explicit connection to it...)<br>
<br>
<br>
&gt; On Nov 21, 2018, at 5:41 PM, Sean Kau &lt;<a href="mailto:skau@chromium.org" target="_blank">skau@chromium.org</a>&gt; wrote:<br>
&gt; <br>
&gt; Thanks Till.<br>
&gt; <br>
&gt; To clarify, we don&#39;t consider advertisement on localhost to be a security problem.  But in the spirit of reducing our attack surface we prefer to moderate communication between processes.  Because of this, we prefer not to communicate over the loopback interface.  Instead, we currently use Unix Domain Sockets since we can control access to those using standard user and group permissions.<br>
&gt; <br>
&gt; Sean Kau<br>
&gt; <br>
&gt; On Wed, Nov 21, 2018 at 2:26 PM Till Kamppeter &lt;<a href="mailto:till.kamppeter@gmail.com" target="_blank">till.kamppeter@gmail.com</a>&gt; wrote:<br>
&gt; Hi,<br>
&gt; <br>
&gt; I talked with Sean Kau and David Valleau from Chrome OS (CCed) about the <br>
&gt; implementation of IPP-over-USB with ippusbxd in Chrome OS. Sean told<br>
&gt; <br>
&gt; ----------<br>
&gt; Using DNS-SD on localhost doesn&#39;t fit our security model as we don&#39;t <br>
&gt; want to allow arbitrary processes to talk to each other.<br>
&gt; ----------<br>
&gt; <br>
&gt; This would mean that we cannot implement IPP-over-USB and Printer <br>
&gt; Applications as innitially thought out. They are supposed to make the <br>
&gt; printer available as<br>
&gt; <br>
&gt; ipp://localhost:PORT/ipp/print<br>
&gt; <br>
&gt; with PORT varying so that there can be several devices connected to the <br>
&gt; same machine (and CUPS running in addition). For CUPS (or the printing <br>
&gt; system in general) automatically discovering the devices and creating <br>
&gt; print queues the Printer Applications (and ippusbxd) are supposed to <br>
&gt; advertise themselves via DNS-SD.<br>
&gt; <br>
&gt; This would mean (local-only) advertising of localhost via DNS-SD, which <br>
&gt; Sean considers a security problem. Is this actually a security problem? <br>
&gt; If so, how should Printer Applications (and ippusbxd) actually work?<br>
&gt; <br>
&gt;     Till<br>
&gt; _______________________________________________<br>
&gt; Printing-architecture mailing list<br>
&gt; <a href="mailto:Printing-architecture@lists.linux-foundation.org" target="_blank">Printing-architecture@lists.linux-foundation.org</a><br>
&gt; <a href="https://lists.linuxfoundation.org/mailman/listinfo/printing-architecture" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/printing-architecture</a><br>
<br>
_________________________________________________________<br>
Michael Sweet, Senior Printing System Engineer<br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Sean Kau</div></div>