Configuring an LPRng Server

As an intended replacement for BSD LPD, LPRng works much the same way from a user 's perspective. Indeed, LPRng even uses an /etc/printcap file that's very similar to the file of the same name in a BSD LPD system. LPRng's access control system for operation as a print server, however, is very different. Instead of a simple list of allowed clients in /etc/ hosts . equiv , LPRng supports a much more complex security system, controlled through /etc/lpd.perms .

Configuring /etc/lpd.perms

The /etc/lpd.perms file controls access to the printing system as a whole. There may also be lpd.perms files stored in the spool directories for individual queues (typically /var/spool/lpd/ queuname ). If present, these files provide control over individual queues ” /etc/lpd.perms sets global options.

Whatever the location, lpd.perms contains five types of lines. The first is a comment line, which begins with a pound sign ( # ). Unlike /etc/hosts.lpd , you may add a comment to a line after the main command. These commands take one of four forms:

 DEFAULT ACCEPT DEFAULT REJECT ACCEPT [  key  =  value  [,  value  ]* ]* REJECT [  key  =  value  [,  value  ]* ]* 

The first two forms set the system's default policy ”to accept or reject connections. Most LPRng packages that ship with Linux distributions include a DEFAULT ACCEPT line in /etc/lpd.perms , so these packages are, by default, much more promiscuous than are BSD LPD packages, which normally accept connections only from the localhost address (, the computer on which the software runs). For this reason, it's important that you tighten restrictions on connections by using ACCEPT and REJECT options.

The ACCEPT and REJECT options set specific types of accesses that the server will accept or reject, respectively. You normally follow these options with one of the keys from the Key column of Table 9.2, which you set to a value defined by the Connect through lpc columns of that table. The Connect column defines a basic ability to connect. The Job Spool and Job Print columns define the ability to send a job to the spooler and cause it to print, respectively. The lpq , lprm , and lpc columns define the ability to perform tasks that are normally controlled by the printing utilities of these names . In most cases, giving access to one of these features gives access to all of them ”or at least to all of them that make sense. Some features are meaningless with some keys, or don't take an explicit parameter, as indicated by "-" entries in Table 9.2. You can reverse the meaning of a value by preceding it with NOT . IP addresses may be followed by a slash ( / ) and a netmask to apply to an entire network.

Table 9.2. Keys and Associated Value Types for lpd.perms
Key Connect Job Spool Job Print lpq lprm lpc
SERVICE X R P Q M C for control or S for status
USER - Username Username Username Username Username
HOST Remote Host Host Name Host Name Host Name Host Name Host Name
GROUP - User name User name User name User name User name
IP Remote IP Address Host IP Address Host IP Address Remote IP Address Host IP Address Host IP Address
PORT Port Number Port Number - Port Number Port Number Port Number
REMOTEUSER - Username Username Username Username Username
REMOTEHOST Remote Host Remote Host Host Host Remote Host Remote Host Remote Host
REMOTEGROUP - Username Username Username Username Username
REMOTEIP Remote IP Address Remote IP Address Host IP Address Remote IP Address Remote IP Address Remote IP Address
CONTROLLINE - Pattern Match Pattern Match Pattern Match Pattern Match Pattern Match
PRINTER - Printer Name Printer Name Printer Name Printer Name Printer Name
FORWARD - - - - - -
SAMEHOST - - - - - -
SAMEUSER - - - - - -
SERVER - - - - - -

The options for controlling access can seem quite complex, so it may help to examine some examples. First, consider some lines that are part of most standard /etc/lpd.perms files:


These three lines specify who may use the lprm utility to delete jobs. All three lines include the SERVICE=M option, which indicates that they apply to the lprm functions, as shown by the SERVICE line in Table 9.2. The first line includes the SAMEHOST and SAMEUSER options, which mean that the command will be accepted if it comes from the same computer that submitted the job, and from the user who owns the job. The second line includes the SERVER and REMOTEUSER=root options, which tell the system to allow root on the server system to delete jobs. The final line rejects all other requests for lprm service. (LPRng searches through its control file until it finds an option that matches the incoming command; as long as the two ACCEPT SERVICE=M lines come before the REJECT SERVICE=M line, the ACCEPT lines take precedence for commands that they match.)

As noted earlier, the default LPRng configuration on many distributions is to accept connections from just about anywhere . This is a potentially dangerous configuration, because an outsider could submit print jobs that could waste your paper, ink, and toner, as well as fill your print spool partition or possibly even compromise your system, if there's a security flaw in LPRng. For this reason, it's generally a good idea to limit access to LPRng. You can do this with a packet filter firewall rule, as discussed in Chapter 25, Configuring iptables. I recommend doing this, but I also recommend implementing redundant protections in LPRng itself. Suppose you have a print server that should accept jobs from the network, and from the server computer itself, but not from other addresses. You could accomplish this goal with a pair of lines like the following:


These lines restrict basic connection to the server, and thus the ability to submit print jobs or do anything else. The first line explicitly allows connections from the server itself. (These come over the interface, so using REMOTEIP= instead of SERVER will have the same effect.) Without this line, the next one would block access to the server from itself, which you probably don't want to do. The second line rejects all accesses that don't originate from the network, or which weren't accepted by a preceding line. If you wanted to accept jobs from multiple subnets, you could include an ACCEPT line that accepts jobs from an additional subnet just prior to the REJECT line. It's best to place these lines that operate on service X earlier than other lines that operate on more specific services, unless those other lines are written in a restrictive way; placing the more specific lines earlier could inadvertently let through some types of connection you might prefer not to permit.

Specifying the Server on an LPRng Client

LPRng uses an /etc/printcap file that's very similar to the one use by BSD LPD. In particular, the lp , rm , and rp options, described earlier in the section "Specifying the Server on a BSD LPD Client," apply to both BSD LPD and LPRng. Most other options also apply to both printing systems, although there are a few differences. These are outside the scope of this chapter, though.

BSD LPD and LPRng use the same LPD protocol for network printing, so you can configure an LPRng client to print to a BSD LPD server or vice versa. This interoperability also extends to CUPS, although CUPS also supports extended protocols that are useful only when two CUPS systems interoperate .

Advanced Linux Networking
Advanced Linux Networking
ISBN: 0201774232
EAN: 2147483647
Year: 2002
Pages: 203

Similar book on Amazon © 2008-2017.
If you may any questions please contact us: