SDB:Configurer une imprimante depuis SUSE LINUX 9.0

Un article de openSUSE.

Version: 9.0

Objectif

Vous souhaitez configurer votre imprimante.

Vous trouverez les informations de base dans les manuels qui accompagnent SUSE LINUX 9.0.

Dans cet article, vous trouverez des informations plus détaillées qui décriront surtout les différences et particularités des versions 9.0 et plus récentes de SUSE LINUX comparées aux versions précédentes. À cette fin, consultez également les articles

• "Printer Configuration from SuSE Linux 8.2"
• "Printer Configuration with SuSE Linux 8.1"
• "Printer Configuration with SuSE Linux 8.0"
• "Installing a Printer from SuSE Linux 6.4 to 7.3"
• "Installing a Printer"

CUPS est le système d'impression conseillé pour SUSE LINUX 9.0.

Modifications du service d'impression CUPS (ou plus exactement, du démon cupsd)

1. Le démon cupsd fonctionne en tant qu'utilisateur lp
2. Fonctionnalité généralisée pour BrowseAllow/BrowseDeny
3. Le démon cupsd est activé automatiquement une fois que le paquetage cups a été installé.

Le démon cupsd fonctionne en tant qu'utilisateur lp

Au démarrage, le démon cupsd passe de l'utilisateur root à l'utilisateur lp comme spécifié dans /etc/cups/cupsd.conf

User lp
Group lp
RunAsUser Yes

Avec "RunAsUser No", le démon cupsd continuer à fonctionner comme root.

Avantage :
Sécurité plus importante car le service d'impression CUPS ne fonctionne pas avec des permissions illimitées mais uniquement avec les permissions nécessaires au service d'impression.

Inconvénient :
L'authentification (plus exactement, la vérification du mot de passe) ne peut pas être effectuée via /etc/shadow, car lp n'a aucun accès à /etc/shadow ; c'est l'authentification spécifique à CUPS via /etc/cups/passwd.md5 qui doit être utilisée. Pour cela, on utilise, pqr exemple, dans /etc/cups/cupsd.conf :

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

En outre, vous devez entrer, en tant qu'utilisateur root, un mot de passe spécifique à CUPS pour l'utilisateur root dans /etc/cups/passwd.md5 à l'aide de la commande :

lppasswd -g sys -a root

La vérification du mot de passe avec /etc/shadow se fait à l'aide de "AuthType Basic". Dans ce cas, le démon cupsd doit fonctionner en tant que root (c'est à dire "RunAsUser No").

Autres conséquences :

• Lorsque le démon cupsd fonctionne en tant que lp, /etc/printcap ne peut pas être généré et lp ne peut pas créé de fichiers dans /etc/. Dans ce cas, cupsd crée /etc/cups/printcap tel que spécifié dans /etc/cups/cupsd.conf

Printcap /etc/cups/printcap
Pour que les applications qui ne peuvent lire les files d'attente que depuis /etc/printcap puissent continuer à fonctionner correctement, /etc/printcap est un lien symbolique vers /etc/cups/printcap.

• Dès que le démon cupsd fonctionne en tant que lp, le port 631 ne peut pas être ouvert. En conséquence, cupsd ne peut plus être chargé à nouveau avec "rccups reload". "rccups restart" doit être utilisé à la place.
• Lorsqu'un périphérique tout-en-un de HP (par exemple un OfficeJet HP) est adressé par le service "ptal", cela ne fonctionnera pas si l'utilisateur root a défini un "umask" non adapté lors de l'exécution de "ptal-init setup". Dans ce cas, ptal a créé les répertoires /dev/ptal-printd et /var/run/ptal-* avec des droits d'accès insuffisants. Vous pouvez définir des droits d'accès adaptés qui permettent au démon cupsd d'envoyer de données aux périphériques ptal en tant qu'utilisateur lp à l'aide de

chmod a+rx /dev/ptal-printd /var/run/ptal-*
Vous trouverez plus d'informations relatives aux périphériques tout-en-un de HP dans l'article "HP OfficeJet".

Fonctionnalité généralisée pour BrowseAllow/BrowseDeny

Les conditions d'accès définies pour BrowseAllow et BrowseDeny correspondent maintenant à tous les types de paquets envoyés à cupsd.

Les paramètres par défaut dans /etc/cups/cupsd.conf sont :

BrowseAllow @LOCAL
BrowseDeny All

Ainsi, uniquement les hôtes "LOCAL" peuvent accéder à cupsd. Les hôtes "LOCAL" sont ceux dont l'adresse IP appartient à une interface non point-to-point. Pour tous les autres ordinateurs (et spécialement pour les ordinateurs qui envoie des paquets au démon cupsd via l'interface ppp*), les paquets sont immédiatement rejetés.

Les restrictions d'accès avec BrowseAllow/BrowseDeny sont vérifiées en premier et ont donc la plus haute priorité. Ainsi, avec

BrowseAllow None
BrowseDeny All

tous les paquets de tous les ordinateurs sont immédiatement rejetés, indépendamment des autres paramètres de droits d'accès (tels que <Location />...</Location>). Uniquement les paquets en provenance de "localhost" (127.0.0.1) ne seront pas rejetés.

La différence principale entre les conditions d'accès définies avec BrowseAllow/BrowseDeny et les conditions d'accès définies avec, par exemple, <Location />...</Location> est la suivante :

• Avec BrowseAllow/BrowseDeny, la décision d'accorder ou de refuser l'accès est basée uniquement sur les données contenues dans l'en-tête du paquet. Étant donné qu'aucune des données du paquet n'est traitée pour rejeter des paquets d'un ordinateur sans droit d'accès, cupsd est moins vulnérables à l'accès par des ordinateurs non autorisés ; c'est à dire que la sécurité contre une attaque depuis un ordinateur non autorisé augmente d'autant.
• Avec <Location />...</Location>, la décision d'accorder ou de refuser l'accès est basée sur les données contenues dans le paquet lui-même. Ce processus est complexe et présente pour cupsd plus de points faibles qui peuvent être exploités pour une attaque.

Résultat :
Les restrictions d'accès avec BrowseAllow/BrowseDeny devrait être utilisé pour rejeter immédiatement tout accès depuis un ordinateur non autorisé. Pour BrowseAllow, on entre normalement le réseau depuis lequel un accès est généralement accordé. On peut utiliser plusieurs entrées BrowseAllow pour plusieurs réseaux ou plusieurs hôtes individuels. "BrowseDeny All" refuse l'accès à tous les autres hôtes. Avec <Location />...</Location>, on définit les conditions d'accès exactes.

Nous souhaitons recevoir vos réactions et commentaires :
Dans SUSE LINUX 9.0, la fonctionnalité généralisée pour BrowseAllow/BrowseDeny est implémenté comme le patch "cups-1.1.19-preauth_security.patch".
L'objectif principale de ce patch est d'obtenir la fonctionnalité décrite ci-dessus (décision d'accès exclusivement basée sur les données dans l'en-tête du paquet) sans nécessiter de nouveaux mots de passe dans /etc/cups/cupsd.conf pour la configuration des conditions d'accès étant donné que le but est de modifier le code de cupsd le moins possible.
Ce patch était nécessaire pour activer automatiquement cupsd dans SUSE LINUX 9.0 (voir la section suivante). De plus, il représente une proposition d'approche pour l'amélioration de la sécurité de cupsd. Néanmoins, le patch ne constitue pas la solution idéale. Afin de pouvoir développer une solution parfaite, nous nécessitons les réactions et commentaires de nos clients afin de connaître tous les problèmes éventuels qui pourraient être causés par ce patch.

Le démon cupsd est activé automatiquement une fois que le paquetage cups a été installé.

Les deux points mentionnés ci-dessus sont des conditions nécessaires car, sinon, la sécurité ne serait pas suffisante pour activer automatiquement le démon cupsd. Un pare-feu configuré correctement peut ne pas être disponible dans tous les cas. En conséquence, le démon cupsd lui-même doit répondre à ces conditions de sécurité.

Dans le cas d'une installation standard, le paquetage cups est installé. L'acivation automatique du démon cupsd permet dorénavant un accès confortable aux files d'attente des serveurs du réseau CUPS sans actions manuelles additionnelles. Ainsi, nous répondons à la demande de nombreux clients qui souhaitent un accès confortable "out of the Box" aux files d'attente CUPS dans le réseau, en particulier pour les ordinateurs clients du réseau qui n'ont pas d'imprimante propre.

Changements dans LPRng/lpdfilter

Depuis SUSE Linux 9.0, filtrer dans un système d'impression LPRng/lpdfilter fonctionne comme suit (consultez la section correspondante dans le guide de l'administrateur) :

• Si une imprimante PostScript est connectée, les données PostScript sont envoyées directement à l'imprimante :

données à imprimer
   |
   v
lpdfilter : conversion vers PostScript
   |
   v
Imprimante PostScript

• Si aucune imprimante PostScript n'est connectée, Ghostscript est utilisé pour générer des données spécifiques à l'imprimante.
  Les paramètres spécifiques à l'imprimante pour la commande Ghostscript sont enregistrés aux emplacements suivants ("file_d_attente" doit être remplacé par le nom réel de la file d'attente) :
  • Comme jusqu'à présent, dans la ligne cm du fichier /etc/printcap
  • Comme jusqu'à présent, dans le fichier /etc/lpdfilter/file_d_attente/upp
    
  • Depuis SUSE Linux 9.0, dans le fichier /etc/lpdfilter/warteschlange/ppd également
    C'est le cas lorsque lpdfilter a été configuré avec YaST.
    De cette façon, la conversion en données spécifiques à l'imprimante se fait de la même manière que dans le cas du système d'impression CUPS avec le filtre foomatic-rip qui génère la commande Ghostscript depuis les données dans le même fichier Foomatic PPD qui est utilisé pour le système d'impression CUPS.
    Si lpdfilter est configuré avec YaST, filtrer dans un système d'impression LPRng/lpdfilter fonctionne comme suit :

  données à imprimer
     |
     v
  lpdfilter : conversion vers PostScript uniquement
     |
     |    ____ fichier PPD correspondant au modèle de l'imprimante
     |   |     (/etc/lpdfilter/file_d_attente/ppd)
     v   v
  foomatic-rip : conversion dans le langage de l'imprimante avec Ghostscript
     |
     v
  Imprimante