深入Linux PAM 体系结构
第二类接口通常并不与底层模块一一对应,它们的作用是对底层模块提供支持以及实现应用程序与模块之间的通信等。具体如下:
由于 PAM 模块随需加载,所以各模块始化任务在第一次调用时完成。如果某些模块的清除任务必须在鉴别会话结束时完成,则它们应该使用 pam_set_data()规定清除函数,这些执行清除任务的函数将在应用程序调用 pam_end()接口时被调用。 我们注意到,配置文件也放在了在应用接口层中,它与 PAM API 配合使用,从而达到了在应用中灵活插入所需鉴别模块的目的。它的作用主要是为应用选定具体的鉴别模块,模块间的组合以及规定模块的行为。下面是一个示例配置文件:
图2.示例配置文件 我们可以看到,配置文件有许多登记项(每行对应一个登记项)组成,每一行又分为五列(每列对应一栏),详细解释如下: 第一栏,service表示使用PAM的应用程序,比如login、passwd、rlogin等。这一栏中的 OTHER表示所有没在该文件中显式列出的应用。也就是说,如果所有程序具有相同的需求,整个配置文件只需要一行即可,并且该行的第一栏为OTHER。本例中,因为所有应用程序使用相同的会话模块,所以实际上可以用单行,即
来代替文件中的这些行:
第二栏,module_type 指明程序所用PAM底层模块的类型:auth表示鉴别类模块;account表示帐户类模块;session表示会话类模块;password表示口令类模块。注意,每行只能指定一种类型模块,如果程序需要多种模块的话,可在多行中分别规定。 第三栏,control_flag规定怎么样处理模块的成功和失败情况。单个应用程序可以调用多种底层模块,这通常称为"堆叠",对应于某程序的按照配置文件中出现顺序执行的所有模块成为"堆",堆中的各模块的地位与出错时的处理由control_flag栏的取值决定,它的五种可能的取值分别为required、Requisite、sufficient或_optional,现介绍如下: required--它表示该模块的成功是用户通过鉴别的必要条件,换句话说,只有当对应于应用程序的所有带 required标记的模块全部成功后,该程序才能通过鉴别。同时,如果任何带required标记的模块出现了错误,PAM并不立刻将错误消息返回给应用程序,而是在所有模块都调用完毕后才将错误消息返回调用它的程序。 Requisite--它与required相仿,只有带此标记的模块返回成功后,用户才能通过鉴别,不同之处在于其一旦失败就不再执行堆中后面的其它模块,并且鉴别过程到此结束。 optional--它表示即便该模块失败,用户仍能通过鉴别。在PAM体系中,带有该标记的模块失败后将继续处理下一模块。 sufficient--它表示该模块取得成功是用户通过鉴别的充分条件,也就是说只要标记为sufficient的模块一旦成功,那么PAM便立即向应用程序返回成功而不必尝试任何其他模块。当标记为sufficient的模块失败时,sufficient模块当做 optional对待。 第四栏,module_path指出PAM模块的位置。 第五栏,options用于向特定模块传递相关的选项,然后由模块分析解释这些任选项。比如使用此栏打开模块调试,或向某模块传递诸如超时值之类的参数等。另外,它还用于支持下文所述的口令映射技术。 如果任一栏出现错误,或某模块没有找到,那么所在行被忽略并将其作为严重错误进行记录。 本例中,login程序使用UNIX口令模块进行鉴别,而ftp程序却使用S/Key模块进行鉴别。如我们想改变ftp程序的鉴别方法,比如也用UNIX口令模块进行鉴别,那么我们不必改动源程序,只需将配置文件中的
|