第十四章 使用者的特殊 shell 与 PAM 模块

我们前面一直谈到的大多是一般身份用户与系统管理员 (root) 的相关操作， 而且大多是讨论关于可登陆系统的账号来说。那么换个角度想，如果我今天想要创建的， 是一个『仅能使用 mail server 相关邮件服务的账号，而该账号并不能登陆 Linux 主机』呢？如果不能给予该账号一个口令，那么该账号就无法使用系统的各项资源，当然也包括 mail 的资源， 而如果给予一个口令，那么该账号就可能可以登陆 Linux 主机啊！呵呵～伤脑筋吧～ 所以，底下让我们来谈一谈这些有趣的话题啰！

另外，在本章之前谈到过 /etc/login.defs 文件中，关于口令长度应该默认是 5 个字符串长度，但是我们上面也谈到，该配置值已经被 PAM 模块所取代了，那么 PAM 是什么？为什么他可以影响我们使用者的登陆呢？这里也要来谈谈的！

特殊的 shell, /sbin/nologin

在本章一开头的 passwd 文件结构里面我们就谈过系统账号这玩意儿，这玩意儿的 shell 就是使用 /sbin/nologin ，重点在于系统账号是不需要登陆的！所以我们就给他这个无法登陆的合法 shell。 使用了这个 shell 的用户即使有了口令，你想要登陆时他也无法登陆，因为会出现如下的信息喔：

This account is currently not available.

我们所谓的『无法登陆』指的仅是：『这个使用者无法使用 bash 或其他 shell 来登陆系统』而已， 并不是说这个账号就无法使用其他的系统资源喔！ 举例来说，各个系统账号，打印作业由 lp 这个账号在管理， WWW 服务由 apache 这个账号在管理， 他们都可以进行系统程序的工作，但是『就是无法登陆主机』而已啦！^_^

换个角度来想，如果我的 Linux 主机提供的是邮件服务，所以说，在这部 Linux 主机上面的账号， 其实大部分都是用来收受主机的信件而已，并不需要登陆主机的呢！ 这个时候，我们就可以考虑让单纯使用 mail 的账号以 /sbin/nologin 做为他们的 shell ， 这样，最起码当我的主机被尝试想要登陆系统以取得 shell 环境时，可以拒绝该账号呢！

另外，如果我想要让某个具有 /sbin/nologin 的使用者知道，他们不能登陆主机时， 其实我可以创建『 /etc/nologin.txt 』这个文件， 并且在这个文件内说明不能登陆的原因，那么下次当这个用户想要登陆系统时， 屏幕上出现的就会是 /etc/nologin.txt 这个文件的内容，而不是默认的内容了！

例题：
当使用者尝试利用纯 mail 账号 (例如 myuser3) 时，利用 /etc/nologin.txt 告知用户不要利用该账号登陆系统。
答：
直接以 vi 编辑该文件，内容可以是这样：

[root@www ~]# vi /etc/nologin.txt
This account is system account or mail account.
Please DO NOT use this account to login my Linux server.

##想要测试时，可以使用 myuser3 (此账号的 shell 是 /sbin/nologin) 来测试看看！

[root@www ~]# su - myuser3
This account is system account or mail account.
Please DO NOT use this account to login my Linux server.
[root@www ~]#

结果会发现与原本的默认信息不一样喔！ ^_^

PAM 模块简介

在过去，我们想要对一个使用者进行认证 (authentication)，得要要求用户输入账号口令， 然后透过自行撰写的程序来判断该账号口令是否正确。也因为如此，我们常常得使用不同的机制来判断账号口令， 所以搞的一部主机上面拥有多个各别的认证系统，也造成账号口令可能不同步的验证问题！ 为了解决这个问题因此有了 PAM (Pluggable Authentication Modules, 嵌入式模块) 的机制！

PAM 可以说是一套应用程序编程接口 (Application Programming Interface, API)，他提供了一连串的验证机制，只要使用者将验证阶段的需求告知 PAM 后， PAM 就能够回报使用者验证的结果 (成功或失败)。由于 PAM 仅是一套验证的机制，又可以提供给其他程序所呼叫引用，因此不论你使用什么程序，都可以使用 PAM 来进行验证，如此一来，就能够让账号口令或者是其他方式的验证具有一致的结果！也让程序设计师方便处理验证的问题喔！ (注5)

tu

如上述的图示， PAM 是一个独立的 API 存在，只要任何程序有需求时，可以向 PAM 发出验证要求的通知， PAM 经过一连串的验证后，将验证的结果回报给该程序，然后该程序就能够利用验证的结果来进行可登陆或显示其他无法使用的信息。 这也就是说，你可以在写程序的时候将 PAM 模块的功能加入，就能够利用 PAM 的验证功能啰。 因此目前很多程序都会利用 PAM 喔！所以我们才要来学习他啊！

PAM 用来进行验证的数据称为模块 (Modules)，每个 PAM 模块的功能都不太相同。举例来说， 还记得我们在本章使用 passwd 命令时，如果随便输入字典上面找的到的字符串， passwd 就会回报错误信息了！这是为什么呢？这就是 PAM 的 pam_cracklib.so 模块的功能！他能够判断该口令是否在字典里面！ 并回报给口令修改程序，此时就能够了解你的口令强度了。

所以，当你有任何需要判断是否在字典当中的口令字符串时，就可以使用 pam_cracklib.so 这个模块来验证！ 并根据验证的回报结果来撰写你的程序呢！这样说，可以理解 PAM 的功能了吧？没错！ PAM 的模块也是很重要的一环！

PAM 模块配置语法

PAM 藉由一个与程序相同文件名的配置文件来进行一连串的认证分析需求。我们同样以 passwd 这个命令的呼叫 PAM 来说明好了。 当你运行 passwd 后，这支程序呼叫 PAM 的流程是：

用户开始运行 /usr/bin/passwd 这支程序，并输入口令；
passwd 呼叫 PAM 模块进行验证；
PAM 模块会到 /etc/pam.d/ 找寻与程序 (passwd) 同名的配置文件；
依据 /etc/pam.d/passwd 内的配置，引用相关的 PAM 模块逐步进行验证分析；
将验证结果 (成功、失败以及其他信息) 回传给 passwd 这支程序；
passwd 这支程序会根据 PAM 回传的结果决定下一个动作 (重新输入新口令或者通过验证！)

从上头的说明，我们会知道重点其实是 /etc/pam.d/ 里面的配置文件，以及配置文件所呼叫的 PAM 模块进行的验证工作！ 既然一直谈到 passwd 这个口令修改命令，那我们就来看看 /etc/pam.d/passwd 这个配置文件的内容是怎样吧！

[root@www ~]# cat /etc/pam.d/passwd
#%PAM-1.0  <==PAM版本的说明而已！
auth       include      system-auth <==每一行都是一个验证的过程
account    include      system-auth
password   include      system-auth
验证类别   控制标准     PAM 模块与该模块的参数

在这个配置文件当中，除了第一行宣告 PAM 版本之外，其他任何『 # 』开头的都是批注，而每一行都是一个独立的验证流程， 每一行可以区分为三个字段，分别是验证类别(type)、控制标准(flag)、PAM的模块与该模块的参数。 底下我们先来谈谈验证类别与控制标准这两项数据吧！

第一个字段：验证类别 (Type)

验证类别主要分为四种，分别说明如下：

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)

那么『验证的控制旗标(control flag)』又是什么？简单的说，他就是『验证通过的标准』啦！ 这个字段在管控该验证的放行方式，主要也分为四种控制方式：

required
此验证若成功则带有 success (成功) 的标志，若失败则带有 failure 的标志，但不论成功或失败都会继续后续的验证流程。 由于后续的验证流程可以继续进行，因此相当有利于数据的登录 (log) ，这也是 PAM 最常使用 required 的原因。

requisite
若验证失败则立刻回报原程序 failure 的标志，并终止后续的验证流程。若验证成功则带有 success 的标志并继续后续的验证流程。 这个项目与 required 最大的差异，就在于失败的时候还要不要继续验证下去？由于 requisite 是失败就终止， 因此失败时所产生的 PAM 信息就无法透过后续的模块来记录了。

sufficient
若验证成功则立刻回传 success 给原程序，并终止后续的验证流程；若验证失败则带有 failure 标志并继续后续的验证流程。 这玩意儿与 requisits 刚好相反！

optional
这个模块控件目大多是在显示信息而已，并不是用在验证方面的。
如果将这些控制旗标以图示的方式配合成功与否的条件绘图，会有点像底下这样：

tu

程序运行过程中遇到验证时才会去呼叫 PAM ，而 PAM 验证又分很多类型与控制，不同的控制旗标所回报的信息并不相同。 如上图所示， requisite 失败就回报了并不会继续，而 sufficient 则是成功就回报了也不会继续。 至于验证结束后所回报的信息通常是『succes 或 failure 』而已，后续的流程还需要该程序的判断来继续运行才行。

常用模块简介

谈完了配置文件的语法后，现在让我们来查阅一下 CentOS 5.x 提供的 PAM 默认文件的内容是啥吧！ 由于我们常常需要透过各种方式登陆 (login) 系统，因此就来看看登陆所需要的 PAM 流程为何：

[root@www ~]# cat /etc/pam.d/login
#%PAM-1.0
auth [user_unknown=ignore success=ok ignore=ignore default=bad] pam_securetty.so
auth       include      system-auth
account    required     pam_nologin.so
account    include      system-auth
password   include      system-auth
# pam_selinux.so close should be the first session rule
session    required     pam_selinux.so close
session    include      system-auth
session    required     pam_loginuid.so
session    optional     pam_console.so
# pam_selinux.so open should only be followed by sessions...
session    required     pam_selinux.so open
session    optional     pam_keyinit.so force revoke
# 我们可以看到，其实 login 也呼叫多次的 system-auth ，所以底下列出该配置文件

[root@www ~]# cat /etc/pam.d/system-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth     required     pam_env.so
auth     sufficient   pam_unix.so nullok try_first_pass
auth     requisite    pam_succeed_if.so uid >= 500 quiet
auth     required     pam_deny.so

account  required     pam_unix.so
account  sufficient   pam_succeed_if.so uid < 500 quiet
account  required     pam_permit.so

password requisite    pam_cracklib.so try_first_pass retry=3
password sufficient   pam_unix.so md5 shadow nullok try_first_pass use_authtok
password required     pam_deny.so

session  optional     pam_keyinit.so revoke
session  required     pam_limits.so
session  [success=1 default=ignore] pam_succeed_if.so service in crond quiet \
                      use_uid
session  required     pam_unix.so

上面这个表格当中使用到非常多的 PAM 模块，每个模块的功能都不太相同，详细的模块情报可以在你的系统中找到：

/etc/pam.d/*：每个程序个别的 PAM 配置文件；
/lib/security/*：PAM 模块文件的实际放置目录；
/etc/security/*：其他 PAM 环境的配置文件；
/usr/share/doc/pam-*/：详细的 PAM 说明文件。

例如鸟哥使用未 update 过的 CentOS 5.2 ，pam_nologin 说明文件档在： /usr/share/doc/pam-0.99.6.2/txts/README.pam_nologin。你可以自行查阅一下该模块的功能。 鸟哥这里仅简单介绍几个较常使用的模块，详细的信息还得要您努力查阅参考书呢！ ^_^

PAM的各种模块是开发人员预先开发好的，而我们要做的是合理的使用这些模块，让它们保护需要保护的程序。所以要关注的是PAM的配置文件目录/etc/pam.d/

转自：http://vbird.dic.ksu.edu.tw/linux_basic/0410accountmanager_5.php