1 files changed, 203 insertions, 0 deletions
diff --git a/Linux-PAM/doc/modules/pam_tally.sgml b/Linux-PAM/doc/modules/pam_tally.sgml
new file mode 100644
index 00000000..ee6fad46
--- /dev/null
+++ b/Linux-PAM/doc/modules/pam_tally.sgml
@@ -0,0 +1,203 @@
+<!--
+
+   $Id: pam_tally.sgml,v 1.3 2005/01/16 22:12:25 toady Exp $
+   
+   This template file was written by Andrew G. Morgan <morgan@kernel.org>
+   adapted from text provided by Tim Baverstock.
+-->
+
+<sect1>The login counter (tallying) module
+
+<sect2>Synopsis
+
+<p>
+<descrip>
+
+<tag><bf>Module Name:</bf></tag>
+pam_tally
+
+<tag><bf>Author[s]:</bf></tag>
+Tim Baverstock
+Tomas Mraz
+
+<tag><bf>Maintainer:</bf></tag>
+
+<tag><bf>Management groups provided:</bf></tag>
+auth; account
+
+<tag><bf>Cryptographically sensitive:</bf></tag>
+	
+<tag><bf>Security rating:</bf></tag>
+
+<tag><bf>Clean code base:</bf></tag>
+
+<tag><bf>System dependencies:</bf></tag>
+A faillog file (default location /var/log/faillog)
+
+<tag><bf>Network aware:</bf></tag>
+
+</descrip>
+
+<sect2>Overview of module
+
+<p>
+This module maintains a count of attempted accesses, can reset count
+on success, can deny access if too many attempts fail.
+
+<p>
+pam_tally comes in two parts: <tt>pam_tally.so</tt> and
+<tt>pam_tally</tt>. The former is the PAM module and the latter, a
+stand-alone program. <tt>pam_tally</tt> is an (optional) application
+which can be used to interrogate and manipulate the counter file. It
+can display users' counts, set individual counts, or clear all
+counts. Setting artificially high counts may be useful for blocking
+users without changing their passwords. For example, one might find it
+useful to clear all counts every midnight from a cron job.
+
+<p>
+The counts file is organized as a binary-word array, indexed by
+uid. You can probably make sense of it with <tt>od</tt>, if you don't
+want to use the supplied appliction.
+
+<p>
+Note, there are some outstanding issues with this module:
+<tt>pam_tally</tt> is very dependant on <tt>getpw*()</tt> - a database
+of usernames would be much more flexible
+
+<sect3>Generic options accepted by both components
+<p>
+<itemize>
+<item> <tt>onerr=</tt>(<tt>succeed</tt>|<tt>fail</tt>):
+   if something weird happens, such as unable to open the file, how
+   should the module react?
+<item> <tt>file=</tt><em>/where/to/keep/counts</em>:
+   specify the file location for the counts.
+   The default location is <tt>/var/log/faillog</tt>.
+<item> <tt>audit</tt>:
+   display the username typed if the user is not found. It may be 
+   useful for scripts, but you should know users often type their
+   password instead making your system weaker. Activate it only if you
+   know what you are doing.
+</itemize>
+
+<sect2>Authentication component
+
+<p>
+<descrip>
+
+<tag><bf>Recognized arguments:</bf></tag>
+<tt>onerr=</tt>(<tt>succeed</tt>|<tt>fail</tt>);
+<tt>file=</tt>/where/to/keep/counts;
+<tt>deny=</tt><em>n</em>;
+<tt>lock_time=</tt><em>n</em>;
+<tt>unlock_time=</tt><em>n</em>;
+<tt>magic_root</tt>;
+<tt>even_deny_root_account</tt>;
+<tt>per_user</tt>;
+<tt>no_lock_time</tt>
+<tt>no_reset</tt>;
+
+<tag><bf>Description:</bf></tag>
+
+<p>
+The authentication component first checks if the user should be denied
+access and if not it increments attempted login counter.
+Then on call to <tt>pam_setcred</tt> it resets the attempts counter 
+if the user is NOT magic root.
+
+<p>
+<tag><bf>Examples/suggested usage:</bf></tag>
+
+<p>
+The <tt>deny=</tt><em>n</em> option is used to deny access if tally
+for this user exceeds <em>n</em>.
+
+<p>
+The <tt>lock_time=</tt><em>n</em> option is used to always deny access
+for at least <em>n</em> seconds after a failed attempt.
+
+<p>
+The <tt>unlock_time=</tt><em>n</em> option is used to allow access after
+<em>n</em> seconds after the last failed attempt with exceeded tally.
+If this option is used the user will be locked out only for the specified
+amount of time after he exceeded his maximum allowed attempts. Otherwise
+the lock is removed only by a manual intervention of the system administrator.
+
+<p>
+The <tt>magic_root</tt> option is used to indicate that if
+the module is invoked by a user with uid=0, then the counter is not
+incremented. The sys-admin should use this for user launched services,
+like <tt>su</tt>, otherwise this argument should be omitted.
+
+<p>
+By way of more explanation, when a process already running as root
+tries to access some service, the access is <em>magic</em>, and
+bypasses <tt>pam_tally</tt>'s checks: this is handy for <tt>su</tt>ing
+from root into an account otherwise blocked. However, for services
+like <tt>telnet</tt> or <tt>login</tt>, which always effectively run
+from the root account, root (ie everyone) shouldn't be granted this
+magic status, and the flag `magic_root' should not be set in this
+situation, as noted in the summary above.
+
+<p>
+Normally, failed attempts to access root will <bf>NOT</bf> cause the
+root account to become blocked, to prevent denial-of-service: if your
+users aren't given shell accounts and root may only login via
+<tt>su</tt> or at the machine console (not
+<tt>telnet</tt>/<tt>rsh</tt>, etc), this is safe. If you really want
+root to be blocked for some given service, use
+<tt>even_deny_root_account</tt>.
+
+<p>
+If <tt>/var/log/faillog</tt> contains a non-zero <tt>.fail_max/.fail_locktime</tt>
+field for this user then the <tt>per_user</tt> module argument will
+ensure that the module uses this value and not the global
+<tt>deny/lock_time=</tt><em>n</em> parameter.
+
+<p>
+The <tt>no_lock_time</tt> option is for ensuring that the module does
+not use the <tt>.fail_locktime</tt> field in /var/log/faillog for this
+user.
+
+<p>
+The <tt>no_reset</tt> option is used to instruct the module to not reset
+the count on successful entry.
+
+</descrip>
+
+<sect2>Account component
+
+<p>
+<descrip>
+
+<tag><bf>Recognized arguments:</bf></tag>
+<tt>onerr=</tt>(<tt>succeed</tt>|<tt>fail</tt>);
+<tt>file=</tt>/where/to/keep/counts;
+<tt>magic_root</tt>;
+<tt>no_reset</tt>;
+
+<tag><bf>Description:</bf></tag>
+
+<p>
+The account component resets attempts counter if the user is NOT 
+magic root. This phase can be used optionaly for services which don't call
+pam_setcred correctly or if the reset should be done regardless
+of the failure of the account phase of other modules.
+
+<tag><bf>Examples/suggested usage:</bf></tag>
+
+<p>
+The <tt>magic_root</tt> option is used to indicate that if
+the module is invoked by a user with uid=0, then the counter is not
+decremented/reset. The sys-admin should use this for user launched services,
+like <tt>su</tt>, otherwise this argument should be omitted.
+
+<p>
+The <tt>no_reset</tt> option is used to instruct the module to not reset
+the count on successful entry.
+
+</descrip>
+
+<!--
+End of sgml insert for this module.
+-->