歡迎來到Linux教程網
Linux教程網
Linux教程網
Linux教程網
Linux教程網 >> Unix知識 >> 關於Unix >> Linux文件權限隱藏的細節深入分析

Linux文件權限隱藏的細節深入分析

日期:2017/3/6 15:47:57   编辑:關於Unix
linux是一個 安全 的操作系統,她是以文件為基礎而設計的,其文件權限是比較復雜的,可以用stat命令以及lsattr命令來顯示某個文件的詳細信息: stat file1 file: `file1' size: 11904 blocks: 24 io block: 4096 regular file device: 301h/769d inode: 3559
  linux是一個安全的操作系統,她是以文件為基礎而設計的,其文件權限是比較復雜的,可以用stat命令以及lsattr命令來顯示某個文件的詳細信息:
  $ stat file1
  file: `file1'
  size: 11904 blocks: 24 io block: 4096 regular file
  device: 301h/769d inode: 355982 links: 1
  aclearcase/" target="_blank" >ccess: (0755/-rwxr-xr-x) uid: ( 503/ jack) gid: ( 503/ general)
  access: 2003-10-19 09:14:12.000000000 +0800
  modify: 2003-10-14 20:41:21.000000000 +0800
  change: 2003-10-19 18:56:25.000000000 +0800
  
  $ lsattr file
  ----i--a----- file
  可以看到,文件權限的含義是比較廣的,先來看-rwxr-xr-x,第一位是文件的類型,它定義了用戶只能某種方式來操作文件,後面九位是文件的存取控制信息,linux的文件許可機制將用戶分為三類:文件屬主u(user)、文件屬組g(group)和其它用戶o(other)。三類不同的用戶可以對文件擁有三種不同級別的權限:讀r(read)、寫w(write)和運行x(execute)。於是形成了九位的權限信息,分為三組,分別對應u,g, o。除此之外,用戶還可以設置setuid與setgid位來改變程序的執行身份。用lsattr命令則可以看到文件的屬性,控制位包括 asacddiijsttu,這些也是能控制文件的存取的。
  由於篇幅有限,不可能就這些一一進行分析,本文著力分析文件權限中w(write)的真正含義,挖出其背後隱藏的細節,力圖使讀者能正確用好這個關鍵的權限位,不至於在系統管理中出現差漏。
  為了能更直觀的說明問題,本文采用實驗操作的方式,一步一步的進行分析。為了簡化操作,我們用o(other)這組權限來做實驗。實驗中用到的權限位均屬於o(other), 進行操作的用戶均非root用戶,屬於o(other)。
  在實驗之前,必須澄清一個概念,目錄也是一種文件,它主要包括了兩方面的信息,該目錄下文件的文件名稱與文件inode編號,它們之間有一一對應的關系。不過目錄文件比較特殊,不能用常規的方法進行讀寫,必須用系統的專用命令來操作。命令ls其實是對目錄文件進行讀操作,命令mv,rm則是對目錄文件進行寫操作。
  好了,該說說w(write)的真正含義了,一句話,linux文件權限中的w是對該文件的*內容*進行限定。下面的實驗可以驗證。
  
  實驗1, 目錄文件: /test(rwx), 普通文件: /test/file(r--). 當前目錄:/test
  
  $ echo "abc" >file
  bash: file: permission denied
  試圖對file的內容進行改寫, 但file的權限是只讀,很顯然,操作失敗。
  
  $ cat file
  hello world!
  沒有問題, 可以讀出file的內容。
  
  $ mv file file2
  $ ls
  file2
  這是怎麼回事呢, file的權限明明是只讀啊, 請注意, 前面提到了, 文件中的rw權限只是針對當前文件的內容進行限定, 文件名不屬於當前文件的內容, 它是保存在上一級的目錄文件的內容中。而mv命令表面上是針對file的,其實是對/test的內容進行改寫,再看看/test的權限, 是可寫的(rwx)。許多用戶為了保護文件,將其權限設成只讀就不管了,這是非常危險的,誠然,可以達到保護文件內容的目的(其實也未必,補充內容中有論述),但你卻不能保證文件是否會被更名或被刪除,保險的方法是將文件父目錄的權限也設為只讀。當然,也有其他的方法,比如用chattr +i命令或將文件系統用ro方式掛載等等,但這些不在本文論述范圍。
  
  $ rm -f file2
  $ ls
  $
  同樣的原因, 我們可以刪除file2, 與上一次操作不同的是,我們不是改寫/test的一條紀錄,而是在刪除/test的一條紀錄。
  
  實驗2, 目錄文件: /test(r-x), 普通文件: /test/file(rw-), 當前目錄:/test
  
  $ echo "abc" >file
  $ cat file
  abc
  /test的權限雖然是只讀,但我們改寫的是file的內容, 它的權限是可寫,當然沒有問題。
  
  $ mv file file2
  mv: cannot move 'file' to 'file2': permission denied
  $ rm -f file
  rm: cannot remove 'file': permission denied
  我們已經知道, 這兩條指令其實與file的權限無關, 而是在改寫/test的內容, 當然操作失敗。通過前面幾個操作,我們應該要分清楚指令真正的操作對象是誰,這樣才能對文件權限作出正確的設定。
  
  實驗3, 目錄文件: /test(rwx), 普通文件: /test/file(r--), 目錄文件: /test/dir(r-x), 普通文件: /test/dir/file(rw-), 當前目錄:/test
  
  $ mv file file2
  $ mv dir dir2
  $ ls
  dir2 file2
  很順利, 因為/test/file與/test/dir的父目錄/test的權限給的太寬松了,是rwx。
  
  $ rm -f file2
  $ rm -rf dir2
  rm: cannot remove 'dir2/file': permission denied
  $ ls -r
  .:
  dir2
  
  ./dir2:
  file
  到這裡, 我們已經絲毫不奇怪普通文件/test/file2被刪除, 但具有同等地位的目錄文件/test/dir2卻安然無恙。當執行rm -rf dir2時, 由於存在普通文件/test/dir2/file, 系統便嘗試先刪除它, 也就相當於修改目錄文件/test/dir2的內容, 但它的權限是只讀, 不能進行修改,也就相當於不能刪除/test/dir2/file, 又由於/test/dir2與/test/dir2/file有依存關系, /test/dir2也就自然會被保留下來。
  回顧上一個操作(mv dir dir2),為什麼目錄文件/test/dir卻可以被更名呢?由於更名操作並不涉及到自身的內容被修改,修改的只是父目錄的內容,而進行刪除操作時,父目錄的內容固然要被修改,但也同時也要修改自身的內容(因為要刪除該目錄下的文件),這就不被允許了。如果/test/dir2的權限是可寫, 或者目錄下沒有子文件, 那麼它的下場就和/test/file2一樣, 被刪除。
  通過前面的幾個操作,可以看到,文件有這麼幾個關鍵狀態:被讀、被改寫、被改名、被刪除、被執行。然而系統只區分三種權限,即讀、寫、執行(rwx)。那麼改名與刪除這兩個操作是否系統就置之不理了呢?不是的,系統將這兩個操作歸入被操作文件的上一級目錄來管理。那麼又是以何種方式來管理的呢?答案是目錄將其下的所有文件看作是它的內容。這樣,當用戶更名或刪除某個文件時,執行的是對上一級目錄的寫操作,屬於rwx三種權限之一的w操作,並沒有逃出系統的管理范圍。
  我們的大腦總是活躍的, 能想象出各種各樣的事情, 能把許多簡單的東西組合成很復雜東西, 上面幾個實驗不正是這樣嗎, 象這樣的實驗我們還可以設計出許多, 但做的越多, 腦子似乎越亂(我已經有一點了), 你能記的住這麼多嗎? ok, 我們也許能將它想的簡單一些, 只需注意兩個方面, 一是要清楚目錄的內容是什麼;二是要明白文件權限中的w(write)的真正含義。仔細想想, 不是嗎?
  
  補充:
  在實驗1中, 如果用vim對file進行編輯, 並且強制保存(w!), 是可以成功的。這並不是說vim就可以繞開系統的安全機制,而是vim耍了一個小小的把戲,它是先刪除這個文件,而後又生成一個同名的新文件。但有一個情況例外,就是當這個文件有另外一個硬鏈接文件存在時,vim會拒絕強制保存,仔細想想,當進行刪除操作後,文件還存在,並沒有被真正刪除,而這時再新建一個文件,雖然同名,但已經不是原來的那個文件了!筆者曾對此事也頗為疑惑,為了求證,仔細閱讀了vim6.2的源代碼,才找到答案。有興趣的讀者也可看一看,具體內容在src/fileio.c中。

Copyright © Linux教程網 All Rights Reserved