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?
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?
Thanks,
Sean
signature.asc
Description: Message signed with OpenPGP
