pam_filter
Filter authentication requests based on criteria
SYNOPSIS
This module is configured within PAM service files, typically in the session type:
session optional pam_filter.so [module options]
PARAMETERS
filter=/path/to/filter_program
Specifies the path to an external program that will be used to filter the I/O. This program should be designed to read from stdin and write to stdout.
filter_user=username
Runs the specified filter program as the given username instead of the user whose session is being filtered or root. This is useful for security sandboxing.
no_input
Disables the filtering of standard input (stdin). Only output streams (stdout, stderr) will be filtered.
no_output
Disables the filtering of standard output (stdout). Only input (stdin) and standard error (stderr) will be filtered.
no_stderr
Disables the filtering of standard error (stderr). Only input (stdin) and standard output (stdout) will be filtered.
quiet_filter_fail
Prevents the logging of errors if the external filter program fails to execute or returns a non-zero exit status. This can be used to avoid excessive log spam from transient filter issues.
debug
Enables verbose debugging messages to be logged to syslog, which can be helpful for troubleshooting filter configurations.
DESCRIPTION
The pam_filter module is a Pluggable Authentication Modules (PAM) component designed to intercept and process input and output streams during a user's session, typically for console logins. It acts as an intermediary, allowing an external filter program to be applied to the standard input (stdin), standard output (stdout), and standard error (stderr) of a user's session.
While not a standalone command, it is configured within PAM service files (e.g., in /etc/pam.d/login or /etc/pam.d/sshd) using the session module type. Its primary applications historically included implementing accessibility features (e.g., screen readers, magnifying tools), logging all console activity for auditing or security purposes, or enforcing specific input/output policies. It was often associated with the pam_console module for managing local console access.
CAVEATS
Using pam_filter introduces a potential security risk if the external filter program is not carefully chosen, secured, and audited, as it runs with elevated privileges or within a user's session context.
It can also introduce performance overhead due to the inter-process communication and execution of an external program for every I/O operation. In modern Linux distributions, its functionality for console management has largely been superseded by systemd-logind, which manages console and seat access more robustly. Therefore, pam_filter is less commonly used today for general console management but might still be relevant for specific, niche I/O filtering requirements.
CONFIGURATION EXAMPLE
To enable pam_filter for a service, you would add a line similar to the following in the relevant PAM configuration file (e.g., /etc/pam.d/login):
session optional pam_filter.so filter=/usr/local/bin/my_io_logger debug
This example pipes all console I/O through /usr/local/bin/my_io_logger and enables debugging. Ensure the filter program exists and has appropriate permissions.
FILTER PROGRAM REQUIREMENTS
The external filter program specified by the filter= option must be executable and capable of reading from its standard input and writing to its standard output. It typically acts as a simple pipe, possibly modifying, logging, or analyzing the data passing through it. For example, a filter might convert character encodings, log every keystroke, or censor specific output.
HISTORY
The pam_filter module emerged as part of older console management solutions, often bundled with or complementing pam_console, particularly in environments where direct console access required strict controls or specialized accessibility features. Its design reflects a time before the widespread adoption of modern session managers like systemd-logind, which now handle many aspects of user session and device allocation. While still available on some systems, its practical usage has significantly declined in favor of more integrated and secure system-level solutions.