Purpose of a pam_confuser module is to allow user to configure their own authentication process. We believe that in modern, flexible and multi-user system the user itself should be able to define how his account should be authenticated.
As was said, configuration of authentication process is the main purpose of pam_confuser module but to fit well into a PAM model, pam_confuser can be also used to configure other PAM management groups. So user can defined also a stack of modules that are invoked at the start/end of his session or when his authentication token is updated.
It might seem that this is very dangerous solution. Unexperienced or incautious user might not purposely allow some “hackers” to gain his privileges in the system.
But looking at the problem from system side, we should agree that system should be secured as well from outside as from inside. It is a fact that there are more security holes available for someone that have account in certain system than for someone who doesn't. But we shall agree there should not be such holes at all. Consider a situation in which some system user becomes a “hacker” or want to take revenge on his system administrators and gives his password to some “hackers”. With our module we give system users more flexibility so we deny more responsibility!
Module do not check user identity by itself but executes modules defined by user. Users manage their own configuration files. Syntax of this files is similar to PAM syntax.
Depends on what management group was module called from, it calls accurate functions from user defined modules. So, as was said, it can manage user modules from all PAM management groups.
User defined modules are invoked using pam-module-interface so many of available PAM-modules can be used or new can be written. But you should notice that now user is able to configure module by setting his parameters! So modules should be written considering this or they should be invoked with user privileges. We know that some modules need super user privileges from their nature (access to passwords files or devices for ex), so we provide a mechanism for system administrator to define which modules should run with root privileges and which with authenticating user privileges. In pam_confuser configuration file, system administrator defines, which modules for which services and which users will run on user or root privileges and which ones will be baned at all.
For security reasons users don't have direct access to their config files. Instead we give them tool "pamconf" that allows them to read and write their configuration. Tool syntax is described in manpages. Before taking any action "pamconf" authenticate calling users to be shure that no one else tries to mess user authentication process.
We can compare this solution to solution known to unix users. Consider configuration file as kind of a new password. Instead of having one string responsible for our access we have whole module stack defined by this file. Just like program “passwd”, “pamconf” before changing our stack authenticate us.
Module name is s simple anagram of “userconf” like user configuration. This is rather accurate anagram according to the fact that with our module authentication process can seem a little confusing at first sight.
“pamconf” name should mean something like “pam stack configuration utility”.