blob: 4d3b4e840b669d9390f4877fd40e9d680be0d723 (plain
This file was written by Andrew G. Morgan <email@example.com>
<sect1>The filter module
Andrew G. Morgan <firstname.lastname@example.org>
<tag><bf>Management groups provided:</bf></tag>
account; authentication; password; session
<tag><bf>Clean code base:</bf></tag>
This module compiles cleanly on Linux based systems.
To function it requires <em/filters/ to be installed on the system.
<sect2>Overview of module
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).
<tt/debug/; <tt/new_term/; <tt/non_term/; <tt/runX/
Each component of the module has the potential to invoke the desired
filter. The filter is always <tt/execv(2)/d with the privilege of the
calling application and <bf/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 <bf/Linux-PAM/ configuration file:
this option increases the amount of information logged to
<tt/syslog(3)/ as the module is executed.
the default action of the filter is to set the <tt/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
<tt/PAM_TTY/ to the filtered pseudo-terminal.
don't try to set the <tt/PAM_TTY/ item.
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 <tt/X/ are <tt/1/ and <tt/2/. These indicate the
precise time that the filter is to be run. To understand 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 <em/authentication/ and <em/session/ components
there are actually two separate functions. For the case of
authentication, these functions are <tt/_authenticate/ and
<tt/_setcred/ -- here <tt/run1/ means run the filter from the
<tt/_authenticate/ function and <tt/run2/ means run the filter from
<tt/_setcred/. In the case of the session modules, <tt/run1/ implies
that the filter is invoked at the <tt/_open_session/ stage, and
<tt/run2/ for <tt/_close_session/.
For the case of the account component. Either <tt/run1/ or <tt/run2/
may be used.
For the case of the password component, <tt/run1/ is used to indicate
that the filter is run on the first occasion <tt/_chauthtok/ is run
(the <tt/PAM_PRELIM_CHECK/ phase) and <tt/run2/ is used to indicate
that the filter is run on the second occasion (the
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 \
End of sgml insert for this module.