printing from the mac sandbox
Sean Reilly
sreilly at seanreilly.com
Thu Jun 1 10:17:03 UTC 2017
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
More information about the macosx-port-dev
mailing list