|
 |
|
| |
19.6 Special Features in SUSE Linux Enterprise
A number of CUPS features have been
adapted for SUSE Linux Enterprise. Some of the most important
changes are covered here.
19.6.1 CUPS Server and Firewall
There are several ways to configure CUPS as the client of a
network server.
-
For every queue on the network server, you can configure
a local queue through which to forward all jobs
to the corresponding network server (forwarding queue). Usually, this
approach is not recommended, because all client machines must
be reconfigured whenever the configuration of the network
server changes.
-
Print jobs can also be forwarded directly to one network server. For this
type of configuration, do not run a local CUPS
daemon. lp or corresponding library calls of other
programs can send jobs directly to the network server. However, this
configuration does not work if you also want to print on a local printer.
-
The CUPS daemon can listen to IPP broadcast packets that other network
servers send to announce available queues.
This is the best CUPS configuration for printing over remote CUPS
servers. However, there is a risk that an attacker sends IPP
broadcasts with queues and the local daemon accesses a counterfeit
queue. If it then displays the queue with the same name as another queue
on the local server, the owner of the job may believe the job is sent to
a local server, while in reality it is sent to the attacker's server.
YaST can find CUPS servers by either scanning local network hosts to see
if they offer the IPP service or by listening to IPP broadcasts. This
requires the firewall to let incoming packets on port 631/UDP (service IPP
client) pass through. This is automatically enabled when you have
configured your machine to be in the internal firewall zone. Opening a port
to configure access to remote queues in the external zone can be a security
risk because an attacker could broadcast a server that might be accepted by
users. By default IPP broadcasts are rejected in the external zone. See
Section 38.4.1,
Configuring the Firewall with YaST for details on firewall configuration.
Alternatively, the user can detect CUPS servers by actively scanning the
local network hosts or configure all queues manually. However, because of
the reasons mentioned in the beginning of this section, this method is not
recommended.
19.6.2 Changes in the CUPS Print Service
These changes were initially applied for SUSE Linux 9.1.
cupsd Runs as the User lp
On start-up, cupsd changes from the user root to the user lp. This provides a much higher level of
security, because the CUPS print service does not run with unrestricted
permissions, only with the permissions needed for the print service.
However, the authentication (the password check) cannot be performed
via /etc/shadow, because lp has no access to
/etc/shadow. Instead, the CUPS-specific
authentication via /etc/cups/passwd.md5 must be
used. For this purpose, a CUPS administrator with the CUPS administration
group sys and a CUPS password
must be entered in /etc/cups/passwd.md5. To do this,
enter the following as root:
lppasswd -g sys -a CUPS-admin-name
This setting is also essential if you want to use the CUPS administration
Web front-end or the KDE printer administration tool.
When cupsd runs as lp, /etc/printcap
cannot be generated, because lp
is not permitted to create files in /etc/.
Therefore, cupsd generates
/etc/cups/printcap. To ensure that applications that
can only read queue names from /etc/printcap continue
to work properly, /etc/printcap is a symbolic link
pointing to /etc/cups/printcap.
When cupsd runs as lp, port 631 cannot be
opened. Therefore, cupsd cannot be reloaded with
rccups reload. Use rccups restart
instead.
Generalized Functionality for
BrowseAllow and
BrowseDeny
The access permissions set for BrowseAllow and
BrowseDeny apply to all kinds of packages sent to
cupsd. The default settings in
/etc/cups/cupsd.conf are as follows:
BrowseAllow @LOCAL
BrowseDeny All
and
<Location />
Order Deny,Allow
Deny From All
Allow From 127.0.0.1
Allow From 127.0.0.2
Allow From @LOCAL
</Location>
In this way, only LOCAL hosts can access
cupsd on a CUPS server. LOCAL hosts
are hosts whose IP addresses belong to a non-PPP interface (interfaces
whose IFF_POINTOPOINT flags are not set) and whose IP
addresses belong to the same network as the CUPS server. Packets from all
other hosts are rejected immediately.
cupsd Activated by Default
In a standard installation, cupsd is activated
automatically, enabling comfortable access to the queues of CUPS network
servers without any additional manual actions. The items in
cupsd Runs as the User lp and
Generalized Functionality for
BrowseAllow and
BrowseDeny are vital preconditions for this
feature, because otherwise the security would not be sufficient for an
automatic activation of cupsd.
19.6.3 PPD Files in Various Packages
The YaST printer configuration sets up the queues for CUPS using only
the PPD files installed in /usr/share/cups/model/ on
the system. To find the suitable PPD files for the printer model, YaST
compares the vendor and model determined during hardware detection with
the vendors and models in all PPD files available in
/usr/share/cups/model/ on the system. For this
purpose, the YaST printer configuration generates a database from the
vendor and model information extracted from the PPD files. When you
select a printer from the list of vendors and models, receive the PPD
files matching the vendor and model.
The configuration using only PPD files and no other information sources
has the advantage that the PPD files in
/usr/share/cups/model/ can be modified freely. The
YaST printer configuration recognizes changes and regenerates the vendor
and model database. For example, if you only have PostScript printers,
normally you do not need the Foomatic PPD files in the
cups-drivers package or the Gimp-Print PPD files
in the cups-drivers-stp package. Instead, the PPD
files for your PostScript printers can be copied directly to
/usr/share/cups/model/ (if they do not already exist
in the manufacturer-PPDs package) to achieve an
optimum configuration for your printers.
CUPS PPD Files in the cups Package
The generic PPD files in the cups package have
been complemented with adapted Foomatic PPD files for PostScript level 1
and level 2 printers:
PPD Files in the cups-drivers Package
Normally, the Foomatic printer filter
foomatic-rip is used together with Ghostscript
for non-PostScript printers. Suitable Foomatic PPD files have the entries
*NickName: ... Foomatic/Ghostscript driver and
*cupsFilter: ... foomatic-rip. These PPD files
are located in the cups-drivers package.
YaST prefers a Foomatic PPD file if a Foomatic
PPD file with the entry *NickName: ... Foomatic ...
(recommended) matches the printer model and the
manufacturer-PPDs package does not contain a
more suitable PPD file.
Gimp-Print PPD Files in the cups-drivers-stp
Package
Instead of foomatic-rip, the CUPS filter
rastertoprinter from Gimp-Print can be used for
many non-PostScript printers. This filter and suitable Gimp-Print PPD
files are available in the cups-drivers-stp
package. The Gimp-Print PPD files are located in
/usr/share/cups/model/stp/ and have the entries
*NickName: ... CUPS+Gimp-Print and
*cupsFilter: ... rastertoprinter.
PPD Files from Printer Manufacturers in the
manufacturer-PPDs Package
The manufacturer-PPDs package contains PPD files
from printer manufacturers that are released under a sufficiently liberal
license. PostScript printers should be configured with the suitable PPD
file of the printer manufacturer, because this file enables the use of all
functions of the PostScript printer. YaST prefers a PPD file from the
manufacturer-PPDs package if the following
conditions are met:
-
The vendor and model determined during the hardware detection
match the vendor and model in a PPD file from the
manufacturer-PPDs package.
-
The PPD file from the manufacturer-PPDs
package is the only suitable PPD file for the printer model or a there
is a Foomatic PPD file with a *NickName: ...
Foomatic/Postscript (recommended) entry that also matches
the printer model.
Accordingly, YaST does not use any PPD file from the
manufacturer-PPDs
package in the following cases:
-
The PPD file from the the manufacturer-PPDs
package does not match the vendor and model. This may happen if the
manufacturer-PPDs package contains only one
PPD file for similar models, for example, if there is no separate PPD
file for the individual models of a model series, but the model name is
specified in a form like Funprinter 1000
series in the PPD file.
-
The Foomatic PostScript PPD file is not
recommended. This may be because
the printer model does not operate efficiently enough in
PostScript mode, for example, the printer may be unreliable in
this mode because it has too
little memory or the printer is too slow because its processor is too weak.
Furthermore, the printer may not support PostScript by
default, for example, because PostScript
support is only available as an optional module.
If a PPD file from the manufacturer-PPDs
package is suitable for a PostScript printer, but YaST cannot configure
it for these reasons, select the respective printer model
manually in YaST.
|
|
|
