sandboxd para back-end do CUPS no Mac OS X Yosemite

Estou usando um back-end do CUPS personalizado para impressão no Mac OS X. O back-end funciona encaminhando os dados de impressão para outra máquina (usando ssh) e alimentando os dados para a impressora a partir daí. Para que isso funcione, o back-end (implementado como um script de shell) precisa acessar uma chave privada ssh. Problema: desde que atualizei para o Yosemite, o script não pode mais acessar o arquivo que contém a chave. Em vez disso, vejo a seguinte mensagem de erro no console:

sandboxd: [...] deny file-read-data /

e

/usr/libexec/cups/backend/.mybackend-ssh/id_dsa: Permission denied

no arquivo de log de erros do CUPS.

Como injetar um arquivo na sandbox usada para isolar os back-ends do CUPS?

Embora isso não responda à pergunta, eu me deparei com isso - http://www.papercut.com/kb/Main/MacOS1010YosemiteKnownIssues - ao tentar fazer com que o Tea4CUPS funcione no OS X 10.10 (não consegui fazer isso):

Para que o PaperCut funcione com o Mac OS 10.10 nesse meio tempo, será necessário desativar o sandboxing. Edite o arquivo /etc/cups/cups-files.conf para incluir a nova linha 'Sandboxing Relaxed'. Depois, reinicie o CUPS para que isso entre em vigor.

sudo sh -c 'echo "Sandboxing Relaxed" >> /etc/cups/cups-files.conf'
sudo launchctl stop org.cups.cupsd

Após uma longa sessão de depuração, finalmente resolvi esse problema. Caso outras pessoas tenham as mesmas dificuldades, eis o que aprendi sobre os back-ends do CUPS no Mac OS X Yosemite:

• Back-ends são arquivos executáveis ​​(no meu caso, um shell script) no /usr/libexec/cups/backend/diretório As informações sobre o trabalho de impressão são transmitidas para esses programas por meio de argumentos da linha de comando ( $1= ID do trabalho, $2= usuário, $3= título, $4= cópias, $5= opções, $6= arquivo) e variáveis ​​de ambiente ( por exemplo $DEVICE_URI ).

• Os back-end são executados como usuário _lp, grupo _lp, com permissões ainda mais restritas pelo sandboxd. O diretório atual quando o back-end é iniciado é o diretório raiz /, mas o back-end não tem permissão para ler este diretório. Listas que podem ser lidos incluem /usr/libexec/cups/backend/, /etc/e subdirectórios destes. Somente o acesso muito restrito (ou nenhum?) Ao diretório inicial do usuário _lp(in /var/spool/cups) é permitido.

• Meu back-end requer o uso de ssh. Para que isso funcione, o ssh precisa ser capaz de acessar a chave privada necessária para efetuar login no servidor remoto e um known_hostsarquivo que identifica o servidor remoto. A chave necessária pode ser colocada em /usr/libexec/cups/backend/um subdiretório ou em um subdiretório; ela deve ser legível apenas pelo usuário _lp. Parece que o ssh, quando iniciado no back-end do CUPS, não tem permissão para acessar /var/spool/cups/.ssh/, mesmo que esse diretório exista; portanto, o known_hostsarquivo deve ser armazenado em /etc/, como /etc/ssh_known_hosts. (Observe que a página do manual ssh afirma incorretamente que isso deve ser /etc/ssh/ssh_known_hosts.)

  Edit: No MacOS X 10.11 (El Capitan), o ssh agora parece usar o local documentado /etc/ssh/ssh_known_hostspara o arquivo hosts conhecido. Eu tive que mover meu arquivo /etc/ssh/para fazer o filtro da impressora funcionar após a atualização do sistema operacional.

• Para depurar problemas como este, o uso cupsctl --debug-loggingé inestimável: Depois que este comando é emitido, tudo o que é gravado em stderr no back-end do CUPS aparece /var/log/cups/error_log. O registro pode ser desligado novamente usando cupsctl --no-debug-logging. Além disso, sempre que o sandboxd negar uma tentativa de acesso ao arquivo, sandboxd[426] ([15998]): sh(15998) deny file-read-data /poderá ser encontrada uma mensagem como /var/log/system.log.