SDB:Drucker einrichten ab SUSE LINUX 9.0

aus openSUSE, der freien Wissensdatenbank

Version: 9.0

Anliegen

Sie möchten Ihren Drucker einrichten.

Die grundlegenden Informationen finden Sie in den Handbüchern zu SUSE LINUX 9.0.

Im folgenden finden Sie weitergehende Informationen, die insbesondere die Unterschiede und Besonderheiten ab SUSE LINUX 9.0 im Vergleich zu früheren Versionen aufzeigen. Vergl. dazu die Artikel

• "Drucker einrichten ab SuSE Linux 8.2"
• "Drucker einrichten ab SuSE Linux 8.1"
• "Drucker einrichten"

Bei SUSE LINUX 9.0 ist CUPS das empfohlene Drucksystem.

Änderungen beim CUPS Druckdienst (genauer: beim cupsd)

1. Der cupsd läuft als Benutzer lp
2. Verallgemeinerte Funktionalität für BrowseAllow/BrowseDeny
3. Der cupsd wird automatisch aktiviert, nachdem das Paket cups installiert wurde.

Der cupsd läuft als Benutzer lp

Der cupsd wechselt nach dem Start vom Benutzer root zum Benutzer lp gemäss /etc/cups/cupsd.conf

User lp
Group lp
RunAsUser Yes

Mit "RunAsUser No" läuft der cupsd dauernd als root.

Vorteil:
Deutlich höhere Sicherheit weil der CUPS Druckdienst nicht mit unbeschränkten Rechten läuft, sondern nur mit solchen Rechten, die für den Druckdienst notwendig sind.

Nachteil:
Die Authentisierung (genauer: die Passwortprüfung) kann nicht mittels /etc/shadow erfolgen, denn lp hat auf /etc/shadow keinen Zugriff und daher funktioniert "AuthType Basic" in diesem Fall nicht. Stattdessen muss die CUPS-spezifische Authentisierung via /etc/cups/passwd.md5 verwendet werden. Dazu dient in /etc/cups/cupsd.conf beispielsweise:

<Location /admin>
AuthType BasicDigest
AuthClass Group
AuthGroupName sys
...
</Location>

Zusätzlich muss als Benutzer root mit dem Befehl

lppasswd -g sys -a root

ein CUPS-spezifisches Passwort für den Benutzer root in /etc/cups/passwd.md5 eingetragen werden. Mit "AuthType Basic" erfolgt die Passwortprüfung mit /etc/shadow wozu der cupsd als root laufen muss (d.h. "RunAsUser No").

Weitere Konsequenzen:

• Wenn der cupsd als lp läuft, kann /etc/printcap nicht erzeugt werden, denn lp darf in /etc/ keine Dateien anlegen. Deswegen legt cupsd /etc/cups/printcap an gemäss /etc/cups/cupsd.conf

Printcap /etc/cups/printcap
Damit Anwendungsprogramme, die die Warteschlangennamen nur aus /etc/printcap lesen können, weiterhin korrekt funktionieren ist /etc/printcap ist ein symbolischer Link auf /etc/cups/printcap.

• Sobald der cupsd als lp läuft, kann der Port 631 nicht geöffnet werden. Deswegen kann der cupsd nicht mehr mit "rccups reload" neu geladen werden. Stattdessen sollte "rccups restart" verwendet werden.
• Wenn HP all-in-one Geräte (z.B. ein HP OfficeJet) via "ptal"-Dienst angesprochen werden, funktioniert das nicht, wenn beim Aufruf von "ptal-init setup" der Benutzer root eine ungeeignete "umask" gesetzt hatte. Dann werden von ptal die Verzeichnisse /dev/ptal-printd und /var/run/ptal-* mit ungenügenden Zugriffsrechten angelegt. Mit

chmod a+rx /dev/ptal-printd /var/run/ptal-*
können geeignete Zugriffsrechte gesetzt werden, damit auch der cupsd als Benutzer lp Daten an ptal-Geräte schicken darf. Mehr Informationen zu HP all-in-one Geräten im Artikel "HP OfficeJet".

Verallgemeinerte Funktionalität für BrowseAllow/BrowseDeny

Die bei BrowseAllow und BrowseDeny gesetzten Zugfriffsbedingungen beziehen sich jetzt auf alle Arten von Paketen, die an den cupsd geschickt werden.

Die defaultmässigen Einstellungen in /etc/cups/cupsd.conf sind:

BrowseAllow @LOCAL
BrowseDeny All

Damit können nur noch LOCAL-Rechner auf den cupsd zugreifen. LOCAL-Rechner sind solche, deren IP-Adresse zu einem nicht-point-to-point Interface gehört. Bei allen anderen Rechnern (also insbesondere Rechner die via ppp*-Interface Pakete an den cupsd schicken) werden die Pakete sofort zurückgewiesen.

Zugfriffsbeschränkungen mittels BrowseAllow/BrowseDeny werden zuerst überprüft und haben daher höchste Priorität. D.h. mit

BrowseAllow None
BrowseDeny All

werden alle Pakete von allen Rechnern sofort zurückgewiesen - unabhängig von sonstigen Zugfriffseinstellungen (etwa bei <Location />...</Location>). Lediglich Pakete von "localhost" (127.0.0.1) werden damit nicht zurückgewiesen.

Der entscheidende Unterschied zwischen Zugfriffsbedingungen mittels BrowseAllow/BrowseDeny und Zugfriffsbedingungen z.B. mittels <Location />...</Location> ist folgender:

• Bei BrowseAllow/BrowseDeny wird die Einscheidung, ob der Zugriff gewährt oder zurückgewiesen wird, nur basierend auf den Daten im Paket-Header gefällt. Da keine Daten aus dem eigentlichen Paket verarbeitet werden, um Pakete von einem unberechtigten Rechner zurückzuweisen, ist hierdurch die Anfriffsfläche, die der cupsd einem unberechtigten Rechner bietet, enorm eingeschränkt. D.h. in gleichem Umfang wächst die Sicherheit gegen einen Angriff von einem unberechtigten Rechner.
• Bei <Location />...</Location> wird die Einscheidung, ob der Zugriff gewährt oder zurückgewiesen wird, basierend auf Daten im eigentlichen Paket gefällt. Dieser Vorgang ist komplex und bietet dementsprechend eine relativ grosse Anfriffsfläche, um Schwachstellen im cupsd für einen Angriff ausnutzen zu können.

Ergebnis:
Zugfriffsbeschränkungen mittels BrowseAllow/BrowseDeny sollten dazu verwendet werden, um jeglichen Zugriff für grundsätzlich unberechtigte Rechner sofort zurückzuweisen. Normalerweise wird man also bei BrowseAllow das Netzwerk eintragen, von dem aus der Zugriff grundsätzlich erlaubt ist - bzw. mit mehreren BrowseAllow Einträgen auch für mehrere Netzwerke oder mehrere einzelne Rechner. Für alle anderen Rechner wird mit "BrowseDeny All" der Zugriff grundsätzlich zurückgewiesen. Mit <Location />...</Location> wird man dann die genauen Zugfriffsbedingungen festlegen.

Bitte um Kundenrückmeldung:
Die verallgemeinerte Funktionalität für BrowseAllow/BrowseDeny ist in SUSE LINUX 9.0 als Patch "cups-1.1.19-preauth_security.patch" implementiert.
Der Grundgedanke bei diesem Patch ist, die oben beschriebene Funktionalität (Zugriffsentscheidung nur mit den Daten im Paket-Header) zu bekommen, ohne dass für die Konfiguration der Zugfriffsbedingungen neue Schlüsselwörter in /etc/cups/cupsd.conf benötigt werden, denn wir wollten so wenig Änderungen wie möglich im Code des cupsd vornehmen.
Dieser Patch war notwendig, um den cupsd bei SUSE LINUX 9.0 automatisch aktivieren zu können (siehe den folgenden Abschnitt). Er ist auch als Vorschlag zu verstehen, wie man die Sicherheit des cupsd verbessern kann, aber vermutlich ist dieser Patch keine endgültige Lösung. Um eine endgültige Lösung entwickeln zu können, sind wir auf Kundenrückmeldung unbedingt angewiesen, damit wir bisher unbekannte Problemfälle, die evtl. durch diesen Patch entstehen, kennen lernen.

Der cupsd wird automatisch aktiviert, nachdem das Paket cups installiert wurde.

Die beiden obigen Punkte sind dafür notwendige Bedingungen, denn andernfalls wäre die Sicherheit nicht hinreichend für eine automatische Aktivierung des cupsd. Eine korrekt konfigurierte Firewall kann nicht als in jedem Fall gegeben angesehen werden. Daher muss der cupsd selbst den Sicherheitsbedingungen genügen.

Bei einer Standardinstallation wird das Paket cups installiert. Die automatische Aktivierung des cupsd ermöglicht nun ohne zusätzliche manuelle Aktionen den komfortablen Zugriff auf Warteschlangen von CUPS-Netzwerk-Servern. Damit kommen wir vielfachem Kundenwunsch nach, die einen komfortablen Zugriff auf CUPS-Warteschlangen im Netzwerk "out of the Box" erwarten - insbesondere für Netzwerk-Client Rechner, die keinen eigenen Drucker angeschlossen haben.

Änderungen bei LPRng/lpdfilter

Bei SUSE Linux 9.0 wird die Filterung beim LPRng/lpdfilter Drucksystem wie folgt ablaufen (vergl. den entsprechenden Abschnitt im Administrationshandbuch):

• Wenn ein PostScript-Drucker angeschlossen ist, werden die Post­Script-Daten direkt an den Drucker geschickt:

zu druckende Daten
   |
   v
lpdfilter: Umwandlung nach PostScript
   |
   v
PostScript-Drucker

• Wenn kein PostScript-Drucker angeschlossen ist, wird Ghostscript verwendet, um die druckerspezifischen Daten zu erzeugen.
  Die druckerspezifischen Parameter für den Ghostscript-Aufruf sind an einer der folgenden Stellen gespeichert ("warteschlange" ist durch den tatsächlichen Namen der Warteschlange zu ersetzen):
  • Wie bisher in der Datei /etc/printcap in der cm-Zeile
  • Wie bisher in der Datei /etc/lpdfilter/warteschlange/upp
    
  • Ab SUSE Linux 9.0 auch in der Datei /etc/lpdfilter/warteschlange/ppd
    Dies ist der Fall, wenn der lpdfilter mit YaST konfiguriert wurde.
    Hierdurch erfolgt die Umwandlung in druckerspezifische Daten auf dieselbe Art wie beim CUPS-Drucksystem mit dem Filter foomatic-rip, der den Ghostscript-Aufruf aus den Daten in derselben Foomatic PPD-Datei erzeugt, die auch für das CUPS-Drucksystem verwendet würde.
    Wird der lpdfilter mit YaST konfiguriert, so läuft die Filterung beim LPRng/lpdfilter Drucksystem wie folgt ab:

  zu druckende Daten
     |
     v
  lpdfilter: nur noch Umwandlung nach PostScript
     |
     |    ____ PPD-Datei passend zum Druckermodell
     |   |     (/etc/lpdfilter/warteschlange/ppd)
     v   v
  foomatic-rip: Umwandlung in die Druckersprache mit Ghostscript
     |
     v
  Drucker