[OpenJDK 2D-Dev] printing from the mac sandbox

[Sean Reilly]

> On 2017.06.02, at 18:06, Phil Race <philip.race at oracle.com> wrote:
>> 2) Is there a reason not to use the unix domain socket connection? The connection details seem to be encapsulated within the libcups code so I don't see why the java level needs to override the result returned by the call to `cupsServer`
> 
> I don't follow your comment about encapsulation in libcups code.
> The server name is returned to Java code and there a connection is made over HTTP.
> The socket string would not work there .. and Java does not have any support I know of
> for Unix domain sockets anyway. This would seem to require a lot of re-working of the
> code unless I am missing something.

I'm not sure how much reworking it would require, but IMO a bug preventing printing in any sandboxed (ie mac app store) app is a big deal.

> Also I asked someone with 10.12.5 to run the following program and it worked fine for them.
> What is your program doing and how are you running it ?

The test code you included wouldn't reveal the problem because it wasn't running within the mac sandbox.

I've created a small test case that shows the problem:
 https://infinitekind.com/tmp/javacups/

 SandboxedJavaTestPrint.zip - has a signed sandboxed java app as well as the source and scripts that were used to build it.  I've signed it with my developer key and added a debugging flag (-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=5005) so that you can trace through the steps while it runs within the sandbox.

 TEST CUPS Sandboxed.zip - contains an objective-c/Xcode project which shows how native connections to localhost port 631 through the CUPS API time out, but how passing the result of a call to cupsServer() (which returns the unix domain socket path) to httpConnect2() results in a successful connection.  This shows that we can still (probably) use a call to httpConnect/httpConnect2, but the java-side code that assumes cupsServer() returns a hostname will need to change.  It's not a trivial change, but it also doesn't look like it gets too hairy... mainly some changes in UnixPrintServiceLocalLookup.java and IPPPrintService.java.

Both test apps have network-client and printing entitlements in the sandbox.

The problem mainly seems to be a delay (often measured in tens of minutes) when attempting to print.  Curiously the print dialog does appear after a very long delay and printing can then proceed.  This makes me think that the problem is related to discovery of printers or print services for which there is a fallback.

I've submitted a DTS incident to Apple and a friend there has followed-up. Their unofficial position is that java should be connecting to the cups interface returned by the cupsServer() function and not changing the interface string to "localhost".  Security changes in 10.12.4 reject the TCP connection which they say confuses network-client access with print access.  They don't seem interested in loosening that change.

You can find Apple's CUPS port in github:  https://github.com/apple/cups
Their github repo seems to be a bit ahead of what is shipped in macOS Sierra.

I'm still digging into this, but would appreciate hearing if Oracle would be interested in helping resolve the issue.

Thanks,
Sean


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20170703/a15caaee/signature.asc>