pam_filter
Andrew G. Morgan <morgan@parc.power.net>
Author.
account; authentication; password; session
Not yet.
This module compiles cleanly on Linux based systems.
To function it requires filters to be installed on the system.
This module was written to offer a plug-in alternative to programs like ttysnoop (XXX - need a reference). Since writing a filter that performs this function has not occurred, it is currently only a toy. The single filter provided with the module simply transposes upper and lower case letters in the input and output streams. (This can be very annoying and is not kind to termcap based editors).
debug
; new_term
; non_term
; runX
Each component of the module has the potential to invoke the desired
filter. The filter is always execv(2)
d with the privilege of the
calling application and not that of the user. For this reason it
cannot usually be killed by the user without closing their session.
The behavior of the module can be significantly altered by the arguments passed to it in the Linux-PAM configuration file:
debug
-
this option increases the amount of information logged to
syslog(3)
as the module is executed.
new_term
-
the default action of the filter is to set the PAM_TTY
item to
indicate the terminal that the user is using to connect to the
application. This argument indicates that the filter should set
PAM_TTY
to the filtered pseudo-terminal.
non_term
-
don't try to set the PAM_TTY
item.
runX
-
in order that the module can invoke a filter it should know when to
invoke it. This argument is required to tell the filter when to do
this. The arguments that follow this one are respectively the full
pathname of the filter to be run and any command line arguments that
the filter might expect.
Permitted values for X
are 1
and 2
. These indicate the
precise time the that filter is to be run. To explain this concept it
will be useful to have read the Linux-PAM Module developer's
guide. Basically, for each management group there are up to two ways
of calling the module's functions.
In the case of the authentication and session components
there are actually two separate functions. For the case of
authentication, these functions are _authenticate
and
_setcred
-- here run1
means run the filter from the
_authenticate
function and run2
means run the filter from
_setcred
. In the case of the session modules, run1
implies
that the filter is invoked at the _open_session
stage, and
run2
for _close_session
.
For the case of the account component. Either run1
or run2
may be used.
For the case of the password component, run1
is used to indicate
that the filter is run on the first occasion _chauthtok
is run
(the PAM_PRELIM_CHECK
phase) and run2
is used to indicate
that the filter is run on the second occasion (the
PAM_UPDATE_AUTHTOK
phase).
At the time of writing there is little real use to be made of this module. For fun you might try adding the following line to your login's configuration entries
#
# An example to see how to configure login to transpose upper and
# lower case letters once the user has logged in(!)
#
login session required pam_filter.so \
run1 /usr/sbin/pam_filter/upperLOWER