分类： LINUX
2013-07-26 14:45:55
验证类别主要分为四种，分别说明如下：
auth 是 authentication (验证) 的缩写，所以这种类别主要用来检验使用者的身份验证，这种类别通常是需要密码来检验的， 所以后续接的模块是用来检验用户的身份。
account account (账号) 则大部分是在进行 authorization (授权)，这种类别则主要在检验使用者是否具有正确的权限， 举例来说，当你使用一个过期的密码来登入时，当然就无法正确的登入了。
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)』又是什么？简单的说，他就是『验证通过的标准』啦！
这个字段在管控该验证的放行方式，主要也分为四种控制方式：
required 此验证若成功则带有 success
(成功) 的标志，若失败则带有 failure 的标志，但不论成功或失败都会继续后续的验证流程。
由于后续的验证流程可以继续进行，因此相当有利于资料的登录 (log) ，这也是 PAM 最常使用 required 的原因。
requisite 若验证失败则立刻回报原程序 failure 的标志，并终止后续的验证流程。若验证成功则带有 success 的标志并继续后续的验证流程。 这个项目与 required 最大的差异，就在于失败的时候还要不要继续验证下去？由于 requisite 是失败就终止， 因此失败时所产生的 PAM 信息就无法透过后续的模块来记录了。
sufficient 若验证成功则立刻回传 success 给原程序，并终止后续的验证流程；若验证失败则带有 failure 标志并继续后续的验证流程。 这玩意儿与 requisits 刚好相反！
optional 这个模块控件目大多是在显示讯息而已，并不是用在验证方面的。
如果将这些控制旗标以图示的方式配合成功不否的条件绘图，会有点像底下这样：
图 5.3.1、 PAM 控制旗标所造成的回报流程
程序运作过程中遇到验证时才会去呼叫 PAM ，而 PAM 验证又分为多类型与控制，不同的控制旗标所回报的讯息并不相同。 如上图所示， requisite 失败就回报了并不会继续，而 sufficient 则是成功就回报了也不会继续。 至于验证结束后所回报的信息通常是『succes 或 failure 』而已，后续的流程还需要该程序的判断来继续执行才行。
