[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    Re: [OpenJDK 2D-Dev] printing from the mac sandbox
From:       Phil Race <philip.race () oracle ! com>
Date:       2017-06-02 17:06:33
Message-ID: 8e78cc64-17d5-d3fd-a6af-c48ede6268eb () oracle ! com
[Download RAW message or body]

see in-line.

On 06/01/2017 08:09 AM, Sean Reilly wrote:
> There is a 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 cupsServer 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 advertised unix domain socket. 
> 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 the sandboxed app has \
> network-client, network-server, and print entitlements, 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.  It \
> seems a bit stubborn of them but to be fair java is ignoring the advertised CUPS \
> server string and assuming that a TCP/localhost:631 interface is available. 
> 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?
Not so far as I know.
> 
> 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.

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 ?
import javax.print.*;

public class GAP {

   public static void main(String[] args) {
      System.out.println("get printers");
      long t0 = System.currentTimeMillis();
      PrintService[] printers =
          PrintServiceLookup.lookupPrintServices(null, null);
      long t1 = System.currentTimeMillis();
      System.out.println("got printers in " + (t1-t0) + "ms.");
      for (int p=0; p<printers.length; p++) {
         System.out.println(printers[p]);
      }
   }
}

> 
> 3) Is a patch that uses the unix domain socket likely to be accepted, and if so, \
> where should it be sent?

This list.

-phil.
> 
> Thanks,
> Sean
> 
> 


[prev in list] [next in list] [prev in thread] [next in thread]