Authorizing Remote Access to Printers

By default, the BSD LPD server is closed to outside access, so you must modify the system's configuration to enable this access. By contrast, both LPRng and CUPS ship with defaults that are more open, although individual Linux distributions sometimes modify these defaults. As a general rule, no matter what system you use, you should limit access as much as possible. With a completely open printing system, a miscreant could tie up your resources by printing large jobs, possibly with all-black pages so as to consume as much ink or toner as possible. If an intruder knows of a security bug in a printing system, the intruder might also be able to leverage an open server to provide greater access.

Tip Security is best applied in layers. In addition to restricting access to your printers with the printer software's tools, you should consider creating iptables firewall rules to block unwanted access. Chapter 20, "Controlling Network Access," covers this topic in more detail.

BSD LPD Access Control

The BSD LPD system uses the /etc/hosts.Ipd file as an access control mechanism.

The simplest way to use this file is to fill it with hostnames or IP addresses, one per line. These computers are then authorized to print to any printer in the system's /etc/printcap file. If your network supports Network Information System (NIS) netgroups, you can specify a netgroup by preceding its name with a plus sign and an at-sign ([email protected]). If you want to exclude specific hosts from an otherwise authorized netgroup, you can precede those hosts' names with minus signs (-). For instance, Listing 13.2 shows a sample hosts.Ipd file. This file grants access to gutenberg in the server's own domain,,, and the agroup NIS netgroup. The host is explicitly denied printing access, though, even if that computer is in the agroup NIS netgroup.

Listing 13.2: Sample /etc/hosts.Ipd File gutenberg [email protected]

As a general rule, the safest way to use the /etc/hosts.Ipd file is to list hosts by IP address. Doing so means that a DNS failure can't cause printing problems and also minimizes the risk that a compromised DNS or NIS server could be used to provide bogus authorization for a miscreant.

Warning The /etc/hosts.equiv file can also be used to authorize the use of a BSD LPD server; however, this file also authorizes the use of other servers, such as rlogind. These servers have their own access control mechanisms, and some (including rlogind) should generally be avoided. I recommend checking to be sure you don't have a hosts.equiv file at all or making sure that it is empty if you do have one. Use server-specific files, such as hosts.Ipd, instead.

LPRng Access Control

Unlike BSD LPD, LPRng doesn't use an /etc/hosts.Ipd file to control remote access. Instead, it uses /etc/lpd.perms, which has a much more complex format. A typical default Ipd.perms file consists mostly of comments describing its use, which can be helpful in figuring out the format if you're unfamiliar with it. Many /etc/Ipd.perms files end with a line reading DEFAULT ACCEPT, which means that the default security policy is to accept print jobs from anywhere, if no earlier rules specify otherwise. Rules that can limit this default rule take the following forms:

ACCEPT criterion REJECT criterion

These lines tell LPRng to accept or reject, respectively, connections that match certain criteria. Specification of these criteria can be quite complex, but typically involves providing a service code from Table 13.2 and a specification of who may or may not use the specified service, as summarized in Table 13.3. You can add the keyword NOT to the keys specified in Table 13.3 to reverse the meaning of a restriction. Most of these keys accept parameters, which you specify after an equal sign (=).

Table 13.2: LPRng Service Codes

LPRng Service Code

Affects Service


Connections; affects all services


Job spooling; ability to submit jobs for printing vidpr


Job printing; ability to print jobs already in the queue


Job queries; ability to obtain information about print jobs via Ipq


Job removal; ability to delete jobs vidprm


Job control; ability to control jobs vidpc


Job status; ability to query job status vialpc

Table 13.3: LPRng Host and User Specifications

Key Name





Sets user-by-user security based on a local




Specifies security based on the computer


that originated the print job

Key Name


Parameter Accepted


Sets group-based security based on local groups

Group name


Restricts access based on the originating port number

Port number


Sets user-by-user security based on a remote username



Restricts access based on the computer that's attempting to access the server



Sets group-based security based on a remote group

Group name


Restricts access based on the computer that submits the print job to the LPRng server

IP address


Restricts access based on the target printer

Queue name


True if HOST and REMOTEHOST are the same computer



True if REMOTEUSER is the one who owns the job



True if the job originated onlocalhost


One way to limit remote connections is to add lines like the following before the DEFAULT ACCEPT line in /etc/lpd.perms:



These lines tell LPRng to accept connections (SERVICE=X) from the local computer (SERVER) and to reject connections from any other computer that's not on the network. Because the X service applies to all connections, this rule effectively limits all access to the print server. This configuration should be useful if you want to share your printers locally, but not with the world at large. Of course, you must change to an appropriate IP address and netmask for your network. If your printer shouldn't be shared at all, omit the second line.

You can create finer-grained rules to restrict access in important ways. For instance, you typically don't want users to be able to delete each others' print jobs. For this reason, the default/etc/lpd.perms file includes the following lines:


The first line tells LPRng to allow the job's owner on the submitting computer to submit a removal request. The second line enables root on the server computer itself to do the same. The third line blocks all other job-removal requests.

CUPS Access Control

CUPS models its access control rules after those provided by Apache. These rules reside in the /etc/cups/cupsd.conf file. Among other features, this file includes a series of multiline location specifications, which look like this:

<l_ocation /printers> Order Deny,Allow Deny From All BrowseAllow from BrowseAllow from Allow from Allow from </Location>

Each location applies to a particular type of resource. The printers location applies to all your printers. There's also a root (/) location that applies to all resources and an admin location that determines administrative access. If you want to restrict access differently for some printers than for others, you can create a location for a specific queue by providing the queue name after the /printers location name, as in Location printers/canon to modify the canon queue's accessibility.

Within each location specification, you'll find some combination of other rules that restrict or enable access, expressed as Allow, Deny, BrowseAllow, and BrowseDeny directives. The Allow and Deny directives grant or block access, respectively. The BrowseAllow and BrowseDeny directives determine whether or not other CUPS servers can automatically scan the server in question. All of these directives take a hostname or IP address as an option, following the from keyword. You can use wildcards or network specifications, such as or, to specify entire blocks of computers. The @LOCAL keyword stands for all local computer interfaces. The Order directive tells the system whether to apply Allow or Deny directives first—whichever type comes second takes precedence when there's a conflict.

Interpreting these rules, the preceding example specifies that computers on the network, as well as the server computer itself, are given access to all of the printers. The Deny from All directive, in conjunction with the Order Deny,Allow directive, blocks all other computers from accessing this one's resources.

Warning The CUPS access control tools described here apply to IPP jobs, not to LPD jobs received via cups-lpd. Once accepted bycups-lpd, these jobs look like local print jobs. Therefore, if you want to control LPD access to a CUPS-based print server, you must use other means, such as iptables firewall rules, TCP Wrappers, orxinetd access control rules. These topics are described in more detail in Chapter 20.

0 0

Post a comment