Rule Matching Procedures

LPRng Reference Manual: 24 Sep 2004 (For LPRng-3.8.28)
Prev | Chapter 17. Permissions and Authentication | Next

# 17.2. Rule Matching Procedures

        [not] key                                 assigned value
        [not] key=pattern                         substring match
        [not] key=pattern1,pattern2,pattern3,...  glob and exact
        [not] key=IP1/mask1,IP2/mask2,...         IP address

Each of the indicated values is matched against a list of patterns. The following types of matches are used:

1. assigned value. The keyword has an assigned value which is true (match) or false (no match). Examples are SAMEHOST and SERVER.

2. substring match. The indicated entry is present as a substring in the pattern.

3. GLOB matches. The pattern is interpreted as a GLOB style pattern, where * matches 0 or more characters, and ? matches a single character, and [L-H] specifies a range of characters from L to H, in ASCII order.

4. IP address match. The address must be specified in the standard `nn.nn.nn.nn` format. The mask must be either an integer number corresponding to the number of significant bits, or in the standard `nn.nn.nn.nn` format. Addresses are compared by doing

           ( IPaddr XOR IP ) AND mask

   If the result is 0, then a match results. Note that there may be one or more addresses being checked for; this can occur when a host may have multiple IP addresses assigned to it.

5. integer range match. The pattern has the form low-high, where low and high are integer numbers. The match succeeds if the value is in the specified range.

6. Same IP Address Match. This compares two lists of IP addresses; a match is found when there is one or more common addresses.

## 17.2.1. DEFAULT

        DEFAULT ACCEPT
        DEFAULT REJECT

The DEFAULT rule specifies the default if no rule matches. Normally, there is one DEFAULT entry in a permissions file.

        Example:

        DEFAULT ACCEPT

## 17.2.2. SERVICE

Match type: substring

The SERVICE key is based on the type of request.

Key | Request
--- | ---
Key | Request
C | LPC Control Request
M | lprm Removal Request
P | Printing
Q | lpq Status Request
R | lpr Job Transfer
X | Connection Request

Each of the above codes corresponds either directly to the user command, or a set of subcommands.

If you have an LPC request, you can add an LPC=xxx clause to refine the permissions checking to allow or disallow lpc commands such as `lpc status, printcap, active,` .

        Example:

        # control only from root on server
        ACCEPT SERVICE=C SERVER USER=root
        REJECT SERVICE=C
        # accept all others
        ACCEPT SERVICE=*

## 17.2.3. USER

Match type: GLOB

The USER information is taken from the P (person or logname) information in the print job control file.

        Example:

        # we allow jobs to be spooled
        ACCEPT SERVICE=R
        # now we do the checking at print time
        ACCEPT SERVICE=P USER=root
        REJECT SERVICE=P

## 17.2.4. REMOTEUSER

Match type: GLOB

The REMOTEUSER information is taken from the user information sent with a service request.

Note that one of the flaws of RFC1179 is that an lpq (print status) request does not provide a REMOTEUSER name.

        Example:

        ACCEPT SERVICE=C REMOTEUSER=root,papowell,admin SERVER
        ACCEPT SERVICE=C LPC=status,lpd REMOTEUSER=admin
        REJECT SERVICE=C

## 17.2.5. HOST

Match type: GLOB

The H (host) information in the print job control file is used to do a DNS lookup, and the resulting list of names and addresses is used for matching purposes.

        Example:

        # we allow jobs to be spooled
        ACCEPT SERVICE=R
        # now we do the checking at print time
        # allow from our private subnet
        ACCEPT SERVICE=P HOST=10.0.0.0/8,*.othernet.com
        REJECT SERVICE=P

## 17.2.6. REMOTEHOST

Match type: GLOB

The REMOTEHOST information is obtained by doing a reverse IP name lookup on the remote host IP address and the resulting list of names and addresses is used for matching purposes. If there is no FQDN available, then the IP address in text form will be used.

        Example:

        # allow from our private subnet
        ACCEPT SERVICE=R REMOTEHOST=10.0.0.0/8,*.othernet.com
        REJECT SERVICE=R

## 17.2.7. REMOTEPORT

Match type: integer range

The REMOTEPORT value is the originating port of the TCP/IP connection. The match succeeds if it is in the specified range.

        Example:

        # require connections to originate from privileged port
        ACCEPT SERVICE=X REMOTEPORT=1-1023
        REJECT SERVICE=X

## 17.2.8. PORT

Alias for REMOTEPORT.

## 17.2.9. IP

Alias for HOST.

## 17.2.10. REMOTEIP

Alias for REMOTEHOST.

## 17.2.11. LPC

Match type: GLOB

The requested lpc command. This allows the following permissions line to be used:

        Example:

        #allow remoteuser admin on server to use LPC topq and hold
        ACCEPT SERVICE=C SERVER REMOTEUSER=root
        ACCEPT LPC=topq,hold SERVER REMOTEUSER=papowell
        REJECT SERVICE=C

## 17.2.12. SAMEUSER

Match type: exact string match

Both the REMOTEUSER and USER information must be present and identical.

        Example:

        # LPC users can do anything
        ACCEPT SERVICE=C SERVER REMOTEUSER=root
        REJECT SERVICE=C
        # allow users who sent jobs from the same host to remove them
        ACCEPT SERVICE=M SAMEUSER SAMEHOST
        REJECT SERVICE=M

## 17.2.13. SAMEHOST

Match type: Same IP Address

The REMOTEHOST and HOST address lists are checked; if there is a common value the match succeeds.

        Example:

        # allow root on the same host as user
        # to remove files
        ACCEPT SERVICE=M SAMEHOST REMOTEUSER=root
        REJECT SERVICE=M

## 17.2.14. SERVER

Match type: Matching IP Address

One of the REMOTEHOST addresses must be the same as one of the addresses of the lpd server host, or must be one of the addresses found by looking up the localhost name using `gethostbyname()`.

        Example:

        # allow root on the server full LPC permissions
        ACCEPT SERVICE=C SERVER REMOTEUSER=root
        REJECT SERVICE=C

## 17.2.15. FORWARD

Match type: Address Match

The list of REMOTEHOST and HOST addresses must not have a common entry. This is usually the case when a remote lpd server is forwarding jobs to the lpd server.

        Example:

        # do not accept forwarded jobs or requests
        REJECT SERVICE=* FORWARD

## 17.2.16. GROUP

Match type: modified GLOB

The USER must be present in one of the groups in `/etc/group` or whatever permissions mechanism is used to determine group ownership which matches the GLOB pattern. If the pattern has the form @name, then a check to see if the user is in the named netgroup is done.

        Example:

        ACCEPT SERVICE=P GROUP=admin,@netgroup
        REJECT SERVICE=P

## 17.2.17. REMOTEGROUP

The same rules as for GROUP, but using the REMOTEUSER value.

        Example:

        ACCEPT SERVICE=R REMOTEGROUP=admin,@netgroup
        REJECT SERVICE=R

## 17.2.18. CONTROLLINE

Match type: GLOB

A CONTROLLINE pattern has the form

        X=pattern1,pattern2,...

X is a single upper case letter. The corresponding line must be present in a control file, and the pattern is applied to the line contents.

This pattern can be used to select only files with specific control file information for printing.

## 17.2.19. AUTH

Match type: value

If the current transfer or the transfer used to send a job was authenticated, then AUTH is true or matches.

        Example:

        # reject all non-authenticated transfers
        REJECT NOT AUTH

## 17.2.20. AUTHTYPE

Match type: glob

If the current transfer or the transfer used to send a job was authenticated, then AUTHTYPE is set to the name of the authentication method.

        Example:

        # require kerberos, pgp, or md5 authentication
        REJECT NOT AUTHTYPE=kerberos*,pgp,md5

## 17.2.21. AUTHUSER

Match type: GLOB

The AUTHUSER rule will check to see if the authenticated user identification matches the pattern.

        Example:

        ACCEPT SERVICE=C AUTHTYPE=kerberos* AUTHUSER=admin@ASTART.COM

## 17.2.22. IFIP

Match type: IPmatch, but for IPV6 as well as IPV4

There is a subtle problem with names and IP addresses which are obtained for 'multi-homed hosts', i.e. - those with multiple ethernet interfaces, and for IPV6 (IP Version 6), in which a host can have multiple addresses, and for the normal host which can have both a short name and a fully qualified domain name.

The IFIP (interface IP) field can be used to check the IP address of the interface that accepted the network connection, as reported by the information returned by the accept() system call. Note that this information may be IPV4 or IPV6 information, depending on the origination of the system. This information is used by gethostbyaddr() to obtain the originating host fully qualified domain name (FQDN) and set of IP addresses. Note that this FQDN will be for the originating interface, and may not be the canonical host name. Some systems which use the Domain Name Server (DNS) system may add the canonical system name as an alias.

This entry is deprecated and may not be supported in future releases.

Prev | Home | Next
Permissions and Authentication | Up | Permission File Location