summaryrefslogtreecommitdiff
path: root/Linux-PAM/modules/pam_filter/README
diff options
context:
space:
mode:
Diffstat (limited to 'Linux-PAM/modules/pam_filter/README')
-rw-r--r--Linux-PAM/modules/pam_filter/README94
1 files changed, 94 insertions, 0 deletions
diff --git a/Linux-PAM/modules/pam_filter/README b/Linux-PAM/modules/pam_filter/README
new file mode 100644
index 00000000..64bac608
--- /dev/null
+++ b/Linux-PAM/modules/pam_filter/README
@@ -0,0 +1,94 @@
+#
+# $Id: README,v 1.1.1.1 2001/04/29 04:17:19 hartmans Exp $
+#
+# This describes the behavior of this module with respect to the
+# /etc/pam.conf file.
+#
+# writen by Andrew Morgan <morgan@parc.power.net>
+#
+
+This module is intended to be a platform for providing access to all
+of the input/output that passes between the user and the application.
+It is only suitable for tty-based and (stdin/stdout) applications. And
+is only known to work on Linux based systems.
+
+The action of the module is dictated by the arguments it is given in
+the pam.conf file.
+
+recognized flags are:
+
+ debug print some information to syslog(3)
+
+ new_term set the PAM_TTY item to the new filtered
+ terminal (the default is to set it
+ to be that of the users terminal)
+
+ non_term don't try to set the PAM_TTY item
+
+ run1/run2 these arguments indicate that the
+ module should separate the application
+ from the user and insert a filter
+ program between them. The pathname of
+ the filter program follows the 'runN'
+ argument. Arguments that follow this
+ pathname are passed as arguments to
+ the filter program.
+
+ The distinction between run1 and run2
+ is which of the two functions of
+ the given management-type triggers the
+ execution of the indicated filter.
+
+ type: run1 run2
+ ----- ---- ----
+
+ auth pam_sm_authenticate pam_sm_setcred
+
+ account [ pam_sm_acct_mgmt (either is good) ]
+
+ session pam_sm_open_session pam_sm_close_session
+
+ password pam_sm_chauthtok/PRELIM pam_sm_chauthtok/UPDATE
+
+Note, in the case of 'password' PRELIM/UPDATE indicates which of the
+two calls to pam_sm_chauthtok from libpam (not the application) will
+trigger the filter.
+
+What a filter program should expect:
+------------------------------------
+
+Definitions for filter programs (which may be locally designed) are
+contained in the <security/pam_filter.h> file.
+
+Arguments are not passed to the filter on the command line, since this
+is plainly visible when a user types 'ps -a'. Instead they are passed
+as the filter's environment. Other information is passed in this way
+too.
+
+Here is a list of the environment variables that a filter should
+expect:
+
+ ARGS="filter_path_name argument list"
+ SERVICE="service_name" (as it appears in /etc/pam.conf)
+ USER="username"
+ TYPE="module_fn" (the name of the function in pam_filter.so
+ that invoked the filter)
+
+[This list is likely to grow. If you want something added, email me!]
+
+Among other things this module is intended to provide a useful means
+of logging the activity of users in as discrete a manner as possible.
+
+Existing filters:
+-----------------
+
+Currently, there is a single supplied filter (upperLOWER). The effect
+of using this filter is to transpose upper and lower case letters
+between the user and the application. This is really annoying when you
+try the 'xsh' example application! ;)
+
+TODO: provide more filters...
+ Decide if providing stderr interception is really overkill.
+
+Andrew G. Morgan <morgan@parc.power.net> 1996/5/27
+