1. 程式人生 > >CentOS SUID/SGID/SBIT許可權與其在專案協作中的運用

CentOS SUID/SGID/SBIT許可權與其在專案協作中的運用

本文總結自鳥哥的linux私房菜 檔案與目錄管理篇:http://linux.vbird.org/linux_basic/0220filemanager.php

目錄

一、幾個特殊許可權

1、SUID

當s這個標誌出現在檔案擁有者的x許可權上時,例如使用者資訊檔案/usr/bin/passwd的許可權狀態為:

-rwsr-xr-x. 1 root root 27832 610 2014 /usr/bin/passwd

這樣的許可權就被稱為Set UID ,簡稱SUID。
對於SUID有如下限制和功能:

  • SUID 許可權僅對二進位程式(binary program)有效
  • 執行者對於該程式需要具有x 的可執行許可權
  • 本許可權僅在執行該程式的過程中有效(run-time)
  • 執行者將具有該程式擁有者(owner) 的許可權

舉個例子來說,我們的Linux系統中,所有帳號的密碼都記錄在/etc/shadow這個檔案裡面,這個檔案的許可權為:【———- 1 root root】,意思是這個檔案僅有root可讀且僅有root可以強制寫入而已。既然這個檔案僅有root可以修改,但是我們知道,在centos中一般使用者(例如使用者dmtsai)是能夠用【 passwd 】指令修改自己的密碼的,也就是說一般使用者在修改密碼時也同時改動了/etc/shadow這個檔案的內容,這是否和該檔案的許可權衝突了呢?

當然沒有,這就引出了SUID的功能,因為滿足之前所列的四點限制和功能:

  • passwd是一個二進位制程式
  • dmtsai使用者對passwd具有x許可權
  • 該許可權在執行過程中有效
  • dmtsai會暫時取得passwd擁有者(root)的許可權

由此,dmtsai獲得root的許可權後便可以修改/etc/shadow中自己的密碼資訊,整個過程如下圖所示:
這裡寫圖片描述

不過如果dmtsai 使用cat 去讀取/etc/shadow 時,由於cat 沒有SUID許可權,所以無法讀出其內容。

另外,SUID僅可用在binary program上,不能夠用在shell script上面!這是因為shell script只是將很多的binary執行檔案叫進來執行而已!所以SUID的許可權部分,還是得要看shell script呼叫進來的程式的設定,而不是shell script本身。當然,SUID對於目錄也是無效的。


2、SGID

a)應用於檔案:

當s 標誌在檔案擁有者的x 專案為SUID,那s 在群組的x 時則稱為Set GID,簡稱SGID,對程式和檔案來說,它的限制和功能如下:

  • SGID 對二進位程式有用
  • 程式執行者對於該程式來說,需具備x 的許可權
  • 執行者在執行的過程中將會獲得該程式群組的支援

舉例來說,locate 是centos中一個查詢檔案位置的命令,它是通過讀取和檢索/var/lib/mlocate/mlocate.db中的內容來進行快速搜尋的,我們來看看兩個檔案的許可權:

-rwx--s--x. 1 root slocate /usr/bin/locate
-rw-r-----. 1 root slocate /var/lib/mlocate/mlocate.db

可以看到mlocate.db 除了擁有者和群組支援外其他人是不能讀取的,但是由於locate具有SGID許可權,所以普通使用者在執行locate之後會獲得locate所在群組slocate的支援,而mlocate.db屬於slocate群組,所以這時便能夠讀取mlocate.db檔案。

b)應用於資料夾

除了binary program 之外,事實上SGID 也能夠用在目錄上,這也是非常常見的一種用途!當一個目錄設定了SGID 的許可權後,他將具有如下的功能:

  • 使用者若對於此目錄具有r 與x 的許可權時,該使用者能夠進入此目錄;
  • 使用者在此目錄下的有效群組(effective group)將會變成該目錄的群組;

也就是說,如果使用者在此目錄下具有w 的許可權,則使用者所建立的新檔案的群組與此目錄的群組相同。這就給在該目錄下工作的不同使用者提供了互相訪問對方檔案的可能,這對於協同工作尤為重要。

具體的例子見下文的專案協作部分


3、SBIT

SBIT 即 Sticky Bit,t 標誌在其他成員x許可權的位置。目前只針對目錄有效,對於檔案已經沒有效果了。SBIT 對於目錄的作用是:

  • 當使用者對於此目錄具有w, x 許可權,亦即具有寫入的許可權時
  • 當使用者在該目錄下建立檔案或目錄時,僅有自己與root 才有權力刪除該檔案

舉例來說就是:當甲這個使用者於A目錄是具有群組或其他人的身份,並且擁有該目錄w的許可權,這表示【甲使用者對該目錄內任何人建立的目錄或檔案均可進行”刪除/更名/搬移”等動作】。不過,如果將A目錄加上了SBIT的許可權專案時,則甲只能夠針對自己建立的檔案或目錄進行刪除/更名/移動等動作,而無法刪除他人的檔案。

以上三種許可權的設定

這裡只介紹常用的數字型設定方式
以上三種許可權的數字位於常規三個許可權數字之前,其中:

  • 4 為SUID
  • 2 為SGID
  • 1 為SBIT

例如設定file檔案為SUID與SGID可以這樣寫:

chmod 6774 file

其許可權變為:
-rws rws r-- 

有時候,設定file檔案為:

chmod 7666 file

其許可權變為:
-rwS rwS rwT

為什麼此處的S和T變為大寫了呢?
當 s 與 t 所在位置的 x 許可權為【空】時,s與t會顯示為大寫字母


二、專案協作

有時候在進行一些專案開發時,需要多人合作在同一環境下進行作業,我們一般會選擇將專案組成員放在一個群組裡,規定一個目錄作為工作空間,但是這存在一個問題:儘管是在同一工作空間同一群組,但是成員之間可能仍舊無法互相訪問對方的檔案,比如像下面這種情況:

A與B都是專案組的成員,系統管理員將他們都放到project這個群組裡,同時給他們分配了一個工作空間為/srv/wplace,並設定該工作空間的許可權為 : drwx rwx — root project 。操作如下:

先製作兩人的帳號資料

[root@tang ~]# groupadd project                <==增加新的群組 
[root@tang ~]# useradd -G project alex         <==建立alex帳號,且支援project 
[root@tang ~]# useradd -G project arod         <==建立arod帳號,且支援project 
[root@tang ~]# id manA                         <==查閱alex帳號的屬性 
uid=1001(manA) gid=1002(agroup) groups=1002(agroup), 1001(project ) 
[root@tang ~]# id manB
uid=1002(manB) gid=1003(bgroup) groups=1003(bgroup), 1001(project)  

再建立專案工作空間:

[root@tang ~]# mkdir /srv/wplace
[root@tang ~]# ll -d /srv/wplace
drwxr-xr-x. 2 root root 6 Jun 17 00:22 /srv/wplace

修改工作空間許可權

[root@tang ~]# chgrp project /srv/wplace 
[root@tang ~]# chmod 770 /srv/wplace 
[root@tang ~]# ll -d /srv/wplace 
drwx rwx ---. 2 root project 6 Jun 17 00:22 /srv/wplace

從上面可以看出A B兩人已經在同一群組裡,且該群組可以為他們提供wplace目錄的群組許可權。這時候貌似沒有什麼問題了,但是大多數時候A與B的有效群組並非都為project,如A的有效群組為agroup,B的有效群組為bgroup,這時我們來測試看看兩個使用者的工作情況:

[root@tang ~]# su - manA        <==先切換身份成為manA來處理 
[manA@www ~]$ cd /srv/wplace    <==切換到群組的工作目錄去 
[manA@www ahome]$ touch abcd  <==建立一個空的檔案出來!
[manA@www ahome]$ exit         <==離開manA的身份

[root@tang ~]# su - manB 
[manB@www ~]$ cd /srv/wplace 
[manB@www wplace]$ ll abcd 
-rw-rw-r--. 1 manA agroup 0 Jun 17 00:23 abcd
#仔細看一下上面的檔案,由於群組是agroup ,manB並不支援!
#因此對於abcd這個檔案來說, manB只是屬於其他人範圍,只有r的許可權而
[arod@www ahome]$ exit

由上面的結果我們可以知道,若單純使用傳統的rwx,則對剛剛A建立的abcd這個檔案來說, B可以刪除他,但是卻不能編輯他,然而我們需要的是A B之間能夠互相訪問編輯彼此的檔案,這時候我們便可以引入SGID許可權了


[root@tang ~]# chmod 2770 /srv/wplace 
[root@tang ~]# ll -d /srv/wplace
drwx rws ---. 2 root project 17 Jun 17 00:23 /srv/wplace

測試:使用manA去建立一個檔案,並且查閱檔案許可權看看: 
[root@tang ~]# su - manA
[manA@www ~]$ cd /srv/wplace 
[manA@www wplace]$ touch 1234 
[manA@www wplace]$ ll 1234 
-rw- rw- r--. 1 manA project 0 Jun 17 00:25 1234

可以看到,當wplace擁有SGID許可權時,在其中建立的檔案的群組會強制變為project,這樣A與B都在群組project的支援裡,故而能夠互相訪問和編輯彼此的檔案,從而達到專案協作的目的。