第十四章 使用者的特殊 shell 与 PAM 模块
生活随笔
收集整理的這篇文章主要介紹了
第十四章 使用者的特殊 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.soaccount required pam_unix.so account sufficient pam_succeed_if.so uid < 500 quiet account required pam_permit.sopassword 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.sosession 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
另外，在本章之前談到過 /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.soaccount required pam_unix.so account sufficient pam_succeed_if.so uid < 500 quiet account required pam_permit.sopassword 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.sosession 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
總結
以上是生活随笔為你收集整理的第十四章 使用者的特殊 shell 与 PAM 模块的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 软件工程实践2017——软件产品案例分析
- 下一篇： 织梦后台验证码显示不出来-处理办法