Linux kernel 中的檔案權限設計
===
from: http://lwn.net/Articles/696227/

在 8/2 號的時候，Baole Ni 為了把 kernel 中有關 file permission 的 code 從八進位修改成 macro 的樣式，送了高達 1285 個 patch。David Miller 直接說這是「[patch 史上最糟的一個 submmit](http://lwn.net/Articles/696228/)」。更猛的是，他的 patch 信還送給了不只一位的 developer...

會有這樣的改動是因為，kernel 中有關權限的部份，其實已經在 `linux/stat.h` 已經有 macro 可以使用，像是 `S_IRWXUGO` 或是 `S_IRUGO` 這種表示方式，但大多數在 kernel code 的實作，還是使用 `0444` 這樣的八進位表示方式。

一場大戰就此開打，首先大家在看到這個 patch 之後，先不論他直接送上 1285 個 patch 這樣的神績，Steven Rostedt 在 patch mail 就回應：

>I find 0444 more readable than S_IRUSR | S_IRGRP | S_IROTH.

大家發現，轉換成 macro 的方式沒有比較好閱讀啊！而且還要在 1285 個地方看到 `S_IRUSR | S_IRGRP` 這樣的表示方式，崩潰啦。

最後是 Linus [發出正式的公告](http://lwn.net/Articles/696229/)，說這種 symbolic name 用在 sticky bit 或是 inode mode _type_ number 上還不錯，但是對於 permission bits，糟，糟糕透頂，沒有人應該在 kernel 或是 user space 中使用他們。

還沒結束，八進位表示也是個很糟的方式，[Al Viro](http://lwn.net/Articles/696230/) 指出，這種表示方式還是有可能造成難以發現的錯誤 (lovely potential for typos)。

真正的問題是，POSIX 定義的這些 `S_* macros` 就是難以閱讀，讓開發者難以使用。最後由 Ingo Molnar [提出一個新的變通方法](http://lwn.net/Articles/696231/)，用一套新的 macro 來表示 permission bits.

#define PERM_rw_______	0600
#define PERM_rw_r_____	0640
#define PERM_rw_r__r__	0644
#define PERM_rw_rw_r__	0664
#define PERM_rw_rw_rw_	0666

Ingo 在信裡面給出一個例子，可以看出用八進位表示的時候，你很難去 code review 找出問題。你能在這個 code 看到兩個資安漏洞嗎？

+	__ATTR(l1, 0444, driver_show_l4, NULL);
+	__ATTR(l3, 0446, driver_show_l4, NULL);
+	__ATTR(l2, 04444, driver_show_l4, NULL);
+	__ATTR(l4, 0444, driver_show_l4, NULL);

轉換成新的方式，可以看到 `PERM_r__r__rw_` 跟 `PERM_sr__r__r__` 這兩個部份是很危險的。

+	__ATTR(l1, PERM_r__r__r__,  driver_show_l4, NULL);
+	__ATTR(l3, PERM_r__r__rw_,  driver_show_l4, NULL);
+	__ATTR(l2, PERM_sr__r__r__, driver_show_l4, NULL);
+	__ATTR(l4, PERM_r__r__r__,  driver_show_l4, NULL);

----

Comments
===

Q1. `epa:`為什麼不用 `const int` 而要用 `#define`？