Estoy usando un backend CUPS personalizado para imprimir en Mac OS X. El backend funciona reenviando los datos de impresión a otra máquina (usando ssh) y alimentando los datos a la impresora desde allí. Para que esto funcione, el backend (implementado como un script de shell) necesita acceso a una clave privada ssh. Problema: desde que actualicé a Yosemite, el script ya no puede acceder al archivo que contiene la clave. En su lugar, veo el siguiente mensaje de error en la consola:
sandboxd: [...] deny file-read-data /
y
/usr/libexec/cups/backend/.mybackend-ssh/id_dsa: Permission denied
en el archivo de registro de errores de CUPS.
¿Cómo puedo inyectar un archivo en la zona de pruebas utilizada para aislar los backends de CUPS?
Si bien esto no responde a la pregunta, me topé con esto - http://www.papercut.com/kb/Main/MacOS1010YosemiteKnownIssues - cuando intentaba que Tea4CUPS funcionara en OS X 10.10 (no pude lograr esto):
Para que PaperCut funcione con Mac OS 10.10 mientras tanto, deberá desactivar el sandboxing. Edite el archivo /etc/cups/cups-files.conf para incluir la nueva línea 'Sandboxing Relaxed'. Luego reinicie CUPS para que esto surta efecto.
sudo sh -c 'echo "Sandboxing Relaxed" >> /etc/cups/cups-files.conf'
sudo launchctl stop org.cups.cupsd
Después de una larga sesión de depuración, finalmente resolví este problema. En caso de que otras personas se encuentren con las mismas dificultades, esto es lo que aprendí sobre los backends de CUPS en Mac OS X Yosemite:
Los backends son archivos ejecutables (en mi caso, un script de shell) en el /usr/libexec/cups/backend/directorio. La información sobre el trabajo de impresión se pasa a estos programas a través de argumentos de la línea de comandos ( $1=id-trabajo, $2=usuario, $3=título, $4=copias, $5=opciones, $6=archivo) y variables de entorno ( p. ej. $DEVICE_URI ).
Los backends se ejecutan como usuario _lp, grupo _lp, con permisos más restringidos por sandboxd. El directorio actual cuando se inicia el backend es el directorio raíz /, pero el backend no tiene permiso para leer este directorio. Los directorios que se pueden leer incluyen /usr/libexec/cups/backend/y /etc/subdirectorios de los mismos. Solo se permite un acceso muy restringido (¿o ninguno?) al directorio de inicio del usuario _lp(en )./var/spool/cups
Mi backend requiere el uso de ssh. Para que esto funcione, ssh debe poder acceder a la clave privada requerida para iniciar sesión en el servidor remoto y un known_hostsarchivo que identifique el servidor remoto. La clave requerida se puede colocar en /usr/libexec/cups/backend/o en un subdirectorio, solo debe ser legible por el usuario _lp. Parece que ssh, cuando se inicia desde el backend de CUPS, no tiene permiso para acceder /var/spool/cups/.ssh/, incluso si este directorio existe; por lo tanto, el known_hostsarchivo debe almacenarse en /etc/, como /etc/ssh_known_hosts. (Tenga en cuenta que la página del manual ssh afirma incorrectamente que esto debería ser /etc/ssh/ssh_known_hosts).
Editar: en MacOS X 10.11 (El Capitan), ssh ahora parece usar la ubicación documentada /etc/ssh/ssh_known_hostspara el archivo de hosts conocidos. Tuve que mover mi archivo para /etc/ssh/que el filtro de la impresora funcionara después de la actualización del sistema operativo.
Para depurar problemas como este, el uso cupsctl --debug-logginges invaluable: después de emitir este comando, todo lo escrito en stderr en el backend de CUPS aparece en /var/log/cups/error_log. El registro se puede volver a desactivar mediante cupsctl --no-debug-logging. Además, cada vez que sandboxd niega un intento de acceso a un archivo, sandboxd[426] ([15998]): sh(15998) deny file-read-data /se puede encontrar un mensaje como en /var/log/system.log.
staromeste
jochen