sandboxd para las TAZAS de los "backends" en Mac OS X Yosemite

Después de una larga sesión de depuración, por fin he solucionado este problema. En el caso de que otras personas ejecutan en las mismas dificultades, aquí es lo que he aprendido acerca de TAZAS de motores de bajo Mac OS X Yosemite:

• Los motores son archivos ejecutables (en mi caso, una secuencia de comandos de shell) en la /usr/libexec/cups/backend/ directorio. Información sobre el trabajo de impresión se pasa en estos programas a través de argumentos de línea de comandos ($1=job-id, $2=usuario, $3=título, $4=copias, $5=opciones, $6=archivo) y las variables de entorno (por ejemplo $DEVICE_URI).

• Los motores son ejecutados como usuario _lp, grupo _lp, con permisos restringido por sandboxd. El directorio actual cuando el motor se arranca es el directorio root /, pero el backend no tiene permiso para leer este directorio. Los directorios que se puede leer incluir /usr/libexec/cups/backend/, /etc/ y subdirectorios del mismo. Sólo muy restringido (o ninguno en absoluto?) acceso al directorio home del usuario _lp ( /var/spool/cups) está permitido.

• Mi backend requiere el uso de ssh. Para que esto funcione, ssh necesita ser capaz de tener acceso a la clave privada necesaria para iniciar sesión en el servidor remoto, y un known_hosts archivo que identifica el servidor remoto. La clave necesaria que puede ser colocado en /usr/libexec/cups/backend/ o en un subdirectorio, debe ser legible sólo por el usuario _lp. Parece que ssh, cuando se inicia desde el backend de CUPS, no tiene permiso para acceder a /var/spool/cups/.ssh/, incluso si este directorio no existe; por lo tanto el known_hosts archivo debe estar almacenado en /etc/, /etc/ssh_known_hosts. (Tenga en cuenta que el ssh página de manual incorrectamente afirma que esta debe ser /etc/ssh/ssh_known_hosts.)

  Edit: En MacOS X 10.11 (El Capitan), ssh ahora parece usar el documento en la ubicación de /etc/ssh/ssh_known_hosts de la conocida archivo de hosts. Tuve que mover mi archivo en /etc/ssh/ para hacer el filtro de impresora trabajo después de la actualización del sistema operativo.

• Para depurar problemas como este, usando cupsctl --debug-logging es de un valor incalculable: Después de este comando es emitido, todo lo escrito a stderr en el backend de CUPS aparece en /var/log/cups/error_log. El registro se puede apagar de nuevo el uso de cupsctl --no-debug-logging. Además, siempre que sandboxd niega un intento de acceso al archivo, un mensaje como sandboxd[426] ([15998]): sh(15998) deny file-read-data / puede ser encontrado en /var/log/system.log.