[*Familiar full name of module*, eg. The "allow all" module.]
Synopsis

`Module Name:` [ insert the name of the module Blank is not permitted. ] `Author[s]:` [ Insert author names here Blank is not permitted. If in doubt, put "unknown" if the author wishes to remain anonymous, put "anonymous". ] `Maintainer:` [ Insert names and date-begun of most recent maintainer. ] `Management groups provided:` [ list the subset of four management groups supported by the module. Choose from: account; authentication; password; session. Blank entries are not permitted. Explicitly list all of the management groups. In the future more may be added to libpam! ] `Cryptographically sensitive:` [ Indicate whether this module contains code that can perform reversible (strong) encryption. This field is primarily to ensure that people redistributing it are not unwittingly breaking laws... Modules may also require the presence of some local library that performs the necessary encryption via some standard API. In this case "uses API" can be included in this field. The library in question should be added to the system requirements below. Blank = no cryptography is used by module. ] `Security rating:` [ Initially, this field should be left blank. If someone takes it upon themselves to test the strength of the module, it can later be filled. Blank = unknown. ] `Clean code base:` [ This will probably be filled by the libpam maintainer. It can be considered to be a public humiliation list. :*) I am of the opinion that "gcc -with_all_those_flags" is trying to tell us something about whether the program works as intended. Since there is currently no Security evaluation procedure for modules IMHO this is not a completely unreasonable indication (a lower bound anyway) of the reliability of a module. This field would indicate the number and flavor of warnings that gcc barfs up when trying to compile the module as part of the tree. Is this too tyrannical? Blank = Linux-PAM maintainer has not tested it :) ] `System dependencies:` [ here we list config files, dynamic libraries needed, system resources, kernel options.. etc. Blank = nothing more than libc required. ] `Network aware:` [ Does the module base its behavior on probing a network connection? Does it expect to be protected by the application? Blank = Ignorance of network. ]

Overview of module [ some text describing the intended actions of the module general comments mainly (specifics in sections below). ] [ [ now we have a
level subsection for each of the management groups. Include as many as there are groups listed above in the synopsis ]
[ Account | Authentication | Password | Session ] component

`Recognized arguments:` [ List the supported arguments (leave their description for the description below. Blank = no arguments are read and nothing is logged to syslog about any arguments that are passed. Note, this behavior is contrary to the RFC! ] `Description:` [ This component of the module performs the task of ... ] `Examples/suggested usage:` [ Here we list some doos and don'ts for this module. ]