linux pam

稀烂的翻译。慎入。

现在linux的pam都是基于目录的，即下面提到的B模式。不过其配置文件基本可以参照A模式。

linux pam 配置文件语法：

service type control module-path module-arguments

A /etc/pam.conf文件

B /etc/pam.d 目录，此目录存在时，将忽略/etc/pam.conf文件。

service：不多说。如果是A，直接写入即可。如果是B，会有以service name命令的文件。直接编辑即可。

type：

account使用此模块管理无认证的用户。auth2方面验证用户。首先，他指定应用程序提示用户密码验证或其他方式验证，来确定用户是否真的是他声称的那个用户。其次，通过其信任授权属性，来授予组成员权限或者其他权限。password被用来升级和用户有关的验证。典型的，例如基于‘challenge/response’的验证方式。这里应该是多次交互方式验证什么的，比如密码输入错误3次即被锁定。session这个和用户行为有关系。通常会在用户获取服务前/后发生作用。例如打开/关闭和其他用户数据交换的日志，mount某个目录……

control：

这个指定PAM-API的验证任务失败之后，应该去做的事情。有2中语法。一种是一个单词构成，另一种是value=action这种样式。简单的如下：
required此PAM（pam行）失败最终导致PAM-API报错，不过仅仅在对于此服务的其他模块堆（pam行）被引用之后

requisite和required比较像，不过报错之后，控制权将直接返回应用程序。返回值和第一个失败的required或者

requisite模块有关。值得注意的是，这个FLAG将会防御用户通过不安全媒介获得输入密码机会的可能。

sufficient

optional

include

substack

复杂一点的可以用以下模式：

value1=action1 value2=action2...

module-path

既包含应用程序使用 pam模块文件的全称，又包含其路径。/lib/security 或者 /lib64/security，取决于其构架。

module-arguments

空格分隔的标记列表，用以修改指定行为。这些参数将会对每一个模块进行文档化。注意，如果参数中包含有空格，就应该使用方括弧。squid auth required pam_mysql.so user=passwd_query passwd=mada \              db=eminence [query=select user_name from internet_service \              where user_name='%u' and password=PASSWORD('%p') and \            service='web_proxy']

按照约定，参数中可以使用“[”或者“]”，但是“]”需要用“\]”替代。转义。    

基于目录的配置：

B模式比起A模式更灵活。每个文件都对应一个服务。语法如下：

type control module-path module-arguments

##############################################################################################

Example configuration file entries

In this section, we give some examples of entries that can be present in the Linux-PAM configuration file. As a first attempt at configuring your system you could do worse than to implement these.

If a system is to be considered secure, it had better have a reasonably secure 'other entry. The following is a paranoid setting (which is not a bad place to start!):

## default; deny access#other   auth     required       pam_deny.soother   account  required       pam_deny.soother   password required       pam_deny.soother   session  required       pam_deny.so       

Whilst fundamentally a secure default, this is not very sympathetic to a misconfigured system. For example, such a system is vulnerable to locking everyone out should the rest of the file become badly written.

The module pam_deny (documented in a later section) is not very sophisticated. For example, it logs no information when it is invoked so unless the users of a system contact the administrator when failing to execute a service application, the administrator may go for a long while in ignorance of the fact that his system is misconfigured.

The addition of the following line before those in the above example would provide a suitable warning to the administrator.

## default; wake up! This application is not configured#other   auth     required       pam_warn.soother   password required       pam_warn.so       

Having two 'other auth' lines is an example of stacking.

On a system that uses the /etc/pam.d/ configuration, the corresponding default setup would be achieved with the following file:

## default configuration: /etc/pam.d/other#auth     required       pam_warn.soauth     required       pam_deny.soaccount  required       pam_deny.sopassword required       pam_warn.sopassword required       pam_deny.sosession  required       pam_deny.so       

This is the only explicit example we give for an /etc/pam.d/ file. In general, it should be clear how to transpose the remaining examples to this configuration scheme.

On a less sensitive computer, one on which the system administrator wishes to remain ignorant of much of the power of Linux-PAM, the following selection of lines (in/etc/pam.d/other) is likely to mimic the historically familiar Linux setup.

## default; standard UN*X access#auth     required       pam_unix.soaccount  required       pam_unix.sopassword required       pam_unix.sosession  required       pam_unix.so       

In general this will provide a starting place for most applications.