printing from the mac sandbox

[Sergey Bylokhov]

Hi, Sean.
The correct mailing list for discussion of such issues is: 2d-dev (cc).

----- sreilly at seanreilly.com wrote:

> There seems to be a big printing problem using recent JDKs when
> running within the macOS sandbox as of 10.12.4.
> 
> Looking at the jdk8 sources, CUPSfuncs.c seems to ignore the
> connection point provided by the system CUPS libraries if it returns a
> reference to a unix domain socket address:
> 
>   // Is this a local domain socket?
>   if (strncmp(server, "/", 1) == 0) {
>     cServer = JNU_NewStringPlatform(env, "localhost");
>   } else {
>     cServer = JNU_NewStringPlatform(env, server);
>   }
> 
> This causes the CUPSPrinter.java and CUPSfunc code to connect to
> localhost via TCP port 631 instead of the unix domain socket which
> should be where it connects.
> 
> MacOS Sierra 10.12.4 had some security related changes to the sandbox
> which explicitly blocks connections from a sandboxed app to TCP
> localhost:631.  This blockage (or at least a very long delay) applies
> even if network-client, network-server, and print entitlements are set
> for the app, which means there's no way around the problem.
> 
> I've talked to Apple DTS and they aren't inclined to allow the
> connection to localhost:631, even if the network-client and print
> entitlements are enabled.
> 
> As you can imagine, not being able to print from a desktop app is
> pretty bad for business.
> 
> My questions are:
>  1) Is anyone at Oracle aware of and working on this?
> 
>  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`
> 
>  3) Is a patch that uses the unix domain socket likely to be accepted,
> and if so, where should it be sent?
> 
>  4) Is there a better mailing list for this discussion?
> 
> Thanks,
> Sean