.

session

session

是会议期间的意思，所以

session

管理的就是使用者在这次登入

(

或使用这个指令

)

期间，

PAM

所

给予的环境设定。

这个类别通常用在记录用户登入与注销时的信息！例如，如果你常常使用

su

或者是

sudo

指令的话，

那么应该可以在

/var/log/secure

里面发现很多关于

pam

的说明，而且记载的数据是『

session

open, session close

』的信息！

.

password

password

就是密码嘛！所以这种类别主要在提供验证的修订工作，举例来说，就是修改

/

变更密码啦！

这四个验证的类型通常是有顺序的

，不过也有例外就是了。

会有顺序的原因是，

(1)

我们总是得要先

验证身份

(auth)

后，

(2)

系统才能够½由用户的身份给予适当的授权与权限设定

(account)

，而且

(3)

登入与注销期间的环境才需要设定，

也才需要记录登入与注销的信息

(session)

。如果在运作期间需

要密码修订时，

(4)

才给予

password

的类别。这样说起来，

自然是需要有点顺序吧！

.

第二个字段：验证的控制旗标

(control flag)

那么『验证的控制旗标

(control flag)

』又是什么？简单的说，他就是『验证通过的标准』啦！

这个字

段在管控该验证的放行方式，主要也分为四种控制方式：

.

required

此验证若成功则带有

success (

成功

)

的标志，若失败则带有

failure

的标志，但不论成功或失败都会继续后

续的验证流程。

由于后续的验证流程可以继续½行，因此相当有利于资料的登录

(log)

，这也是

PAM

最

常使用

required

的原因。

.

requisite

若验证失败则立刻回报原程序

failure

的标志，并终止后续的验证流程。若验证成功则带有

success

的标志

并继续后续的验证流程。

这个项目与

required

最大的差异，就在于失败的时候还要不要继续验证下去？由

于

requisite

是失败就终止，

因此失败时所产生的

PAM

信息就无法透过后续的模块来记录了。

.

sufficient

若验证成功则立刻回传

success

给原程序，并终止后续的验证流程；若验证失败则带有

failure

标志并继续

后续的验证流程。

这玩意儿与

requisits

刚好相反！

.

optional

这个模块控件目大多是在显示讯息而已，并不是用在验证方面的。

如果½这些控制旗标以图示的方式配合成功与否的条件绘图，会有点像底下这样：