學(xué)shell到現(xiàn)在了，一直以為自己不會(huì)犯一個(gè)大家常說的非常二的問題，結(jié)果這本書最后的時(shí)候犯了個(gè)十分2的事，晚節(jié)不保?。。?！我在測試文件路徑下除了通配符*和？外還能用啥正則那樣的東西，結(jié)果就在$HOME下執(zhí)行了rm .* 。。。好吧，蛋疼了一下午！還木找回任何一個(gè)配置文件。警示后人，千萬別使用rm試通配符！任何時(shí)候小心使用rm！
第十四章shell可移植性議題和擴(kuò)展
可以先通讀這篇文章。
想寫出好的可移植性shell，不僅要了解各種shell版本間的差異，還要有很多編程技巧，比如盡量從環(huán)境變量中獲取需要的信息等。
第十五章安全的shell腳本：起點(diǎn)
安全性shell腳本的提示：
1、不要將當(dāng)前目錄（點(diǎn)號(hào)）置于PATH下?？蓤?zhí)行程序應(yīng)該只能放在標(biāo)準(zhǔn)的系統(tǒng)目錄下，將當(dāng)前目錄放在PATH里，無疑是打開特洛伊木馬（Trojan Horse）的大門。
2、為bin目錄設(shè)置保護(hù)。確認(rèn)$PATH下的每一個(gè)目錄都只有它的擁有者可以寫入，其余任何人都不能。用樣的道理也應(yīng)該應(yīng)用于bin目錄里所有的程序。
3、寫程序前，先想清除?；c(diǎn)時(shí)間想想你要做什么，該如何實(shí)行。不要一開始就在文字編輯器上寫。錯(cuò)誤與失敗的優(yōu)雅處理也應(yīng)該設(shè)計(jì)在程序里。
4、應(yīng)對(duì)所有輸入?yún)?shù)檢查其有效性。如果期待的是數(shù)字，那就驗(yàn)證它是數(shù)字，并且是否在要求的范圍內(nèi)。其他的需要也是這樣檢測。
5、對(duì)所有可返回錯(cuò)誤的命令，檢查錯(cuò)誤處理代碼。不在你預(yù)期內(nèi)的失敗情況，很可能是有問題的強(qiáng)迫失敗，導(dǎo)致腳本出現(xiàn)不當(dāng)?shù)男袨椤＠?，如果參?shù)為NFS加載磁盤或面向字符的設(shè)備文件時(shí)，即便是以root的身份執(zhí)行，也可能導(dǎo)致有些命令失敗。
6、不要信任傳進(jìn)來的環(huán)境變量。如果它們被接下來的命令（如TZ、PATH、IFS等）使用時(shí)，請(qǐng)檢查并重設(shè)為已知的值。無論在什么情況下，最好的方式就是明確的設(shè)置自己需要的（如PATH只包含系統(tǒng)bin目錄，設(shè)置IFS為空格定位符和換行）。
7、從已知的地方開始。在腳本開始時(shí)，確切cd到已知目錄，這么一來，接下來任何相對(duì)路徑名稱才能指到已知位置。確認(rèn)cd操作成功：cd app-dir || exit 1
8、使用syslog（8）保留審計(jì)跟蹤。記錄引用的日期與時(shí)間、username等，參見logger（1）的使用手冊(cè)。如果沒有l(wèi)ogger，可建立一個(gè)函數(shù)保留日志文件：
復(fù)制代碼 代碼如下:
logger（）{
printf "%s\n" "$*" >> /var/adm/logsysfile
}
logger "Run by user " $(id -un) "($USER) at " $(/bin/date)
9、當(dāng)使用該輸入時(shí)，一定將用戶輸入引用起來。例如："$1"與"$*"，這么做可以防止居心不良的用戶輸入超出范圍的計(jì)算與執(zhí)行。
10、勿在用戶輸入上使用eval。甚至在引用用戶輸入之后，也不要使用eval將它交給shell再處理。如果用戶讀取了你的腳本，發(fā)現(xiàn)你使用eval，就能很輕松的利用這個(gè)腳本進(jìn)行任何破壞。
11、引用通配符展開的結(jié)果。你可以將空格、分號(hào)、反斜杠等放在文件名里，讓棘手的事情交給系統(tǒng)管理員處理。如果管理的腳本未引用文件名參數(shù)，此腳本將會(huì)造成系統(tǒng)的問題。
12、檢查用戶輸入是否有meta字符。如果使用eval或$(...)里的輸入，請(qǐng)檢查是否有像$或`這類的meta字符。
13、檢測你的代碼，并小心謹(jǐn)慎閱讀它。尋找是否有可被利用的漏洞與錯(cuò)誤。把所有壞心眼的想法都考慮進(jìn)去，小心研究你的代碼，試著找出破壞它的方式，再修正發(fā)現(xiàn)的問題。
14、留意競爭條件（race condition）攻擊者是不是可以在你腳本里的任兩個(gè)命令之間執(zhí)行任意命令，這對(duì)安全性是否有危害？如果是，換個(gè)方式處理你的腳本。
15、對(duì)符號(hào)性連接心存懷疑。在chmod文件或是編輯文件時(shí)，檢查它是否真的是一個(gè)文件，而非連接到某個(gè)關(guān)鍵性系統(tǒng)文件的符號(hào)性連接（利用[ -L file ] 或 [ -h file ]檢測file是否為一符號(hào)性連接。
16、找其他人重新檢查你的程序，看看是否有問題。
17、盡可能用setgid而不要用setuid。這些術(shù)語稍后討論，簡之就是使用setgid能將損害范圍限制在某個(gè)組內(nèi)。
18、使用新的用戶而不是root。如果你必須使用setuid訪問一組文件，請(qǐng)考慮建立一個(gè)新的用戶，非root的用戶做這件事并設(shè)置setuid給他。
19、盡可能限制使用setuid的代碼。盡可能讓setuid代碼減到最少。將它移到一個(gè)分開的程序，然后在大型腳本里需要時(shí)才引用它。無論如何，請(qǐng)做好代碼防護(hù)，好像腳本可以被任何人于任何地方引用那樣。
20、一個(gè)安全shell的開場白：
復(fù)制代碼 代碼如下:
IFS=' \t\n' #之前幾篇見過很多次
unset -f unalias #確保unalias不是一個(gè)函數(shù)
\unalias -a #unset all aliases and quote unalias so it's not alias-expanded
unset -f command #確保調(diào)用的command不是以函數(shù)
#獲得可靠的路徑前綴，處理getconf不可用的情況。
#get a reliable path prefix,handling case where getconf is not available.
SYSPATH="$(command -p getconf PATH 2>/dev/null))"
if [[ -z "$SYSPATH" ]];then
SYSPATH="/usr/bin:/bin"
fi
PATH="$SYSPATH:$PATH"
這段代碼使用了許多非POSIX的擴(kuò)展，需要注意。
該書最后給出了如何編寫自己的shell程序的manual，和unix的文件和文件系統(tǒng)的介紹。至此該書通讀完畢。
您可能感興趣的文章:- shell腳本學(xué)習(xí)指南[二](Arnold Robbins & Nelson H.F. Beebe著)
- shell腳本學(xué)習(xí)指南[一](Arnold Robbins & Nelson H.F. Beebe著)
- shell腳本學(xué)習(xí)指南[五](Arnold Robbins & Nelson H.F. Beebe著)
- shell腳本學(xué)習(xí)指南[四](Arnold Robbins & Nelson H.F. Beebe著)
- shell腳本學(xué)習(xí)指南[三](Arnold Robbins & Nelson H.F. Beebe著)
