From sreilly at seanreilly.com  Thu Jun  1 10:17:03 2017
From: sreilly at seanreilly.com (Sean Reilly)
Date: Thu, 1 Jun 2017 11:17:03 +0100
Subject: printing from the mac sandbox
Message-ID: <2457AAE3-CB15-472F-85C0-BC1C68CD255A@seanreilly.com>


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


From philip.race at oracle.com  Thu Jun  1 13:03:43 2017
From: philip.race at oracle.com (Philip Race)
Date: Thu, 01 Jun 2017 06:03:43 -0700
Subject: printing from the mac sandbox
In-Reply-To: <2457AAE3-CB15-472F-85C0-BC1C68CD255A@seanreilly.com>
References: <2457AAE3-CB15-472F-85C0-BC1C68CD255A@seanreilly.com>
Message-ID: <593010AF.1020309@oracle.com>

This list should really be archived as the port  project is over .. 
macos is just another one of the JDK desktop platforms.
So you should re-post this to 2d-dev at openjdk.java.net which is the right 
place to consider a patch too.
And perhaps file a bug at java.com since I don't know of any bug report 
to this effect.

-phil.

On 6/1/17, 3:17 AM, Sean Reilly 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
>

From sergey.bylokhov at oracle.com  Thu Jun  1 15:55:53 2017
From: sergey.bylokhov at oracle.com (Sergey Bylokhov)
Date: Thu, 1 Jun 2017 08:55:53 -0700 (PDT)
Subject: printing from the mac sandbox
Message-ID: <0a1039f3-7f6e-4bbb-81fb-af287cad593d@default>

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