Ich verwende ein benutzerdefiniertes CUPS-Backend zum Drucken unter Mac OS X. Das Backend leitet die Druckdaten an einen anderen Computer (mithilfe von ssh) weiter und leitet die Daten von dort an den Drucker weiter. Damit dies funktioniert, benötigt das Backend (implementiert als Shell-Skript) Zugriff auf einen privaten SSH-Schlüssel. Problem: Seit ich auf Yosemite aktualisiert habe, kann das Skript nicht mehr auf die Datei zugreifen, die den Schlüssel enthält. Stattdessen sehe ich folgende Fehlermeldung auf der Konsole:
sandboxd: [...] deny file-read-data /
Und
/usr/libexec/cups/backend/.mybackend-ssh/id_dsa: Permission denied
in der CUPS-Fehlerprotokolldatei.
Wie kann ich eine Datei in die Sandbox einfügen, die zum Isolieren von CUPS-Backends verwendet wird?
Obwohl dies die Frage nicht beantwortet, bin ich darüber gestolpert - http://www.papercut.com/kb/Main/MacOS1010YosemiteKnownIssues - als ich versuchte, Tea4CUPS in OS X 10.10 zum Laufen zu bringen (ich konnte dies nicht erreichen):
Damit PaperCut in der Zwischenzeit mit Mac OS 10.10 funktioniert, müssen Sie Sandboxing deaktivieren. Bearbeiten Sie die Datei /etc/cups/cups-files.conf, um die neue Zeile „Sandboxing Relaxed“ einzufügen. Starten Sie dann CUPS neu, damit dies wirksam wird.
sudo sh -c 'echo "Sandboxing Relaxed" >> /etc/cups/cups-files.conf'
sudo launchctl stop org.cups.cupsd
Nach einer langen Debugging-Sitzung habe ich dieses Problem endlich gelöst. Falls andere Leute auf die gleichen Schwierigkeiten stoßen, hier ist, was ich über CUPS-Backends unter Mac OS X Yosemite gelernt habe:
Backends sind ausführbare Dateien (in meinem Fall ein Shell-Skript) im /usr/libexec/cups/backend/Verzeichnis. Informationen über den Druckauftrag werden diesen Programmen über Kommandozeilenargumente ( $1=job-id, $2=user, $3=title, $4=copies, $5=options, $6=file) und Umgebungsvariablen ( zB $DEVICE_URI ) übergeben.
_lpBackends werden als user , group ausgeführt _lp, wobei die Berechtigungen durch sandboxd weiter eingeschränkt werden. Das aktuelle Verzeichnis beim Start des Backends ist das Stammverzeichnis /, aber das Backend hat keine Berechtigung, dieses Verzeichnis zu lesen. Zu den Verzeichnissen, die gelesen werden können, gehören /usr/libexec/cups/backend/, /etc/und deren Unterverzeichnisse. Es wird nur ein sehr eingeschränkter (oder gar kein?) Zugriff auf das Home-Verzeichnis von Benutzer _lp(in /var/spool/cups) erlaubt.
Mein Backend erfordert die Verwendung von ssh. Damit dies funktioniert, muss ssh auf den privaten Schlüssel zugreifen können, der für die Anmeldung beim Remote-Server erforderlich ist, sowie auf eine known_hostsDatei, die den Remote-Server identifiziert. Der benötigte Schlüssel kann in /usr/libexec/cups/backend/oder einem Unterverzeichnis abgelegt werden, es darf nur für den Benutzer lesbar sein _lp. Es scheint, dass ssh, wenn es vom CUPS-Backend gestartet wird, keine Berechtigung hat, auf zuzugreifen /var/spool/cups/.ssh/, selbst wenn dieses Verzeichnis existiert; daher known_hostsmuss die Datei in gespeichert werden /etc/, als /etc/ssh_known_hosts. (Beachten Sie, dass die ssh-Manpage fälschlicherweise behauptet, dass dies sein sollte /etc/ssh/ssh_known_hosts.)
Bearbeiten: Unter MacOS X 10.11 (El Capitan) scheint ssh jetzt den dokumentierten Speicherort für die bekannte Hosts-Datei zu verwenden /etc/ssh/ssh_known_hosts. Ich musste meine Datei verschieben, /etc/ssh/damit der Druckerfilter nach dem Betriebssystem-Upgrade funktioniert.
Um solche Probleme zu debuggen, cupsctl --debug-loggingist using von unschätzbarem Wert: Nachdem dieser Befehl ausgegeben wurde, erscheint alles, was im CUPS-Backend in stderr geschrieben wird, in /var/log/cups/error_log. Mit kann die Protokollierung wieder abgeschaltet werden cupsctl --no-debug-logging. Außerdem findet sich immer dann, wenn sandboxd einen versuchten Dateizugriff ablehnt, eine Meldung wie sandboxd[426] ([15998]): sh(15998) deny file-read-data /in /var/log/system.log.
staromeste
jochen