linuxpsthread

『壹』 linux裡面殺掉進程命令是什麼

方法一: Terminal終端輸入: gnome-system-monitor,就可以打開system monitor

如圖:

然後找到相應進程,右擊選擇kill process就可以了

方法二: 通過kill 進程id的方式可以實現,

首先需要知道進程id, 例如,想要殺死firefox的進程,通過 ps -ef|grep firefox,可以查到firefox的進程id:

然後通過 kill 3781 就可以關閉進程了.

補充: 1. kill -9 來強制終止退出, 例如: kill -9 3781

2.特殊用法：

kill -STOP [pid]
發送SIGSTOP (17,19,23)停止一個進程，而並不消滅這個進程。
kill -CONT [pid]
發送SIGCONT (19,18,25)重新開始一個停止的進程。
kill -KILL [pid]
發送SIGKILL (9)強迫進程立即停止，並且不實施清理操作。
kill -9 -1
終止你擁有的全部進程。

方法三: killall 通過程序的名字,來殺死進程

例如: killall firefox
注意: 該命令可以使用 -9 參數來強制殺死進程, killall -9 firefox

方法四: pkill 通過程序的名字, 直接殺死所有進程
例如: pkill firefox

方法五: 通過xkill 可以殺死圖形程序應用, 例如firefox崩潰無響應,可以使用該命令.
例如: 用法xkill , 會出現一個白色的x, 然後用滑鼠單擊想要殺死的應用,如圖

以下內容引用自: http://justcoding.iteye.com/blog/1931347

◆編者註：
KILLALL(Section: User (1)/Updated: 1999年9月7日)
———————————————–

NAME (名稱)
killall – 以名字方式來殺死進程

SYNOPSIS (總覽)
killall [-egiqvw] [-signal] name …
killall -l
killall -V

DESCRIPTION (描述)
killall 發送一條信號給所有運行任意指定命令的進程. 如果沒有指定信號名, 則發送SIGTERM.。
信號可以以名字 (如 -HUP ) 或者數字 (如 -1 ) 的方式指定. 信號 0 (檢查進程是否存在)只能以數字方式指定。
如果命令名包括斜杠 (/), 那麼執行該特定文件的進程將被殺掉, 這與進程名無關。
如果對於所列命令無進程可殺, 那麼 killall 會返回非零值. 如果對於每條命令至少殺死了一個進程, killall 返回 0。Killall 進程決不會殺死自己 (但是可以殺死其它 killall 進程)。

OPTIONS (選項)
-e
對 於很長的名字, 要求准確匹配. 如果一個命令名長於 15 個字元, 則可能不能用整個名字 (溢出了). 在這種情況下, killall 會殺死所有匹配名字前 15 個字元的所有進程. 有了 -e 選項,這樣的記錄將忽略. 如果同時指定了 -v 選項, killall 會針對每個忽略的記錄列印一條消息。
-g
殺死屬於該進程組的進程. kill 信號給每個組只發送一次, 即使同一進程組中包含多個進程。
-i
交互方式，在殺死進程之前徵求確認信息。
-l
列出所有已知的信號名。
-q
如果沒有進程殺死, 不會提出抱怨。
-v
報告信號是否成功發送。
-V
顯示版本信息。
-w
等待所有殺的進程死去. killall 會每秒檢查一次是否任何被殺的進程仍然存在, 僅當都死光後才返回. 注意: 如果信號被忽略或沒有起作用, 或者進程停留在僵屍狀態, killall 可能會永久等待。
FILES(相關文件)
/proc proc文件系統的存在位置。
KNOWN bugS (已知 BUGS)
以文件方式殺死只對那些在執行時一直打開的可執行文件起作用, 也即, 混雜的可執行文件不能夠通過這種方式殺死。
要警告的是輸入 killall name 可能不會在非 Linux 系統上產生預期的效果, 特別是特權用戶執行時要小心。
在兩次掃描的間隙, 如果進程消失了而被代之以一個有同樣 PID 的新進程, killall -w 偵測不到。

來源：http://www.ubuntuhome.com/ubuntu-kill-command.html

下面來了解相關命令：

一、查看進程的命令 有ps、pstree、pgrep等：

1、ps
顯示進程信息，參數可省略
-aux 以BSD風格顯示進程 常用
-efH 以System V風格顯示進程
-e , -A 顯示所有進程
a 顯示終端上所有用戶的進程
x 顯示無終端進程
u 顯示詳細信息
f 樹狀顯示
w 完整顯示信息
l 顯示長列表

在終端中執行ps aux,
各列輸出欄位的含義：

USER 進程所有者
PID 進程ID
PPID 父進程
%CPU CPU佔用率
%MEM 內存佔用率
NI 進程優先順序。數值越大，佔用CPU時間越少
VSZ 進程虛擬大小
RSS 頁面文件佔用
TTY 終端ID
STAT 進程狀態
+---D 不可中斷 Uninterruptible sleep (usually IO)
+---R 正在運行，或在隊列中的進程
+---S 處於休眠狀態
+---T 停止或被追蹤
+---Z 僵屍進程
+---W 進入內存交換（從內核2.6開始無效）
+---X 死掉的進程

+---< 高優先順序
+---N 低優先順序
+---L 有些頁被鎖進內存
+---s 包含子進程
+---+ 位於後台的進程組；
+---l 多線程，克隆線程 multi-threaded (using CLONE_THREAD, like NPTL pthreads do)

PID:進程標識符，系統為每一個進程分配一個識別碼，稱為PID。

ps命令極為常用，其他命令還有：

2.pstree
樹狀顯示進程信息
-a 顯示完整命令及參數
-c 重復進程分別顯示
-c 顯示進程ID PID
-n 按 PID 排列進程

3.pgrep <進程名>
顯示進程的PID
-l 顯示進程名和進程PID
-o 進程起始ID
-n 進程終止ID

二、結束進程的命令 有kill、pkill、killall、xkill等：

kill [信號代碼] <進程PID>

根據PID向進程發送信號，常用來結束進程，默認信號為 -9
信號代碼，可取值如下：
-l [信號數字] 顯示、翻譯信號代碼
-9 , -KILL 發送 kill 信號退出
-6 , -ABRT 發送 abort 信號退出
-15 , -TERM 發送 Termination 信號
-1 , -HUP 掛起
-2 , -INT 從鍵盤中斷，相當於 Ctrl+c
-3 , -QUIT 從鍵盤退出，相當於 Ctrl+d
-4 , -ILL 非法指令
-11 , -SEGV 內存錯誤
-13 , -PIPE 破壞管道
-14 , -ALRM
-STOP 停止進程，但不結束
-CONT 繼續運行已停止的進程
-9 -1 結束當前用戶的所有進程

pkill <進程名>
結束進程族。如果結束單個進程，請用 kill

killall <進程名>
killall和pkill 應用方法差不多，也是直接殺死運行中的程序；如果您想殺掉單個進程，請用kill 來殺掉。

xkill
在圖形界面中點殺進程。
當xkill運行時滑鼠指針變為骷髏圖案，哪個圖形程序崩潰一點就OK了。如果您想終止xkill ，就按右鍵取消。
比如當firefox 出現崩潰不能退出時，點滑鼠就能殺死firefox 。
xkill 調用方法：
[root@localhost ~]# xkill

來源： http://www.cnblogs.com/1024-wusuopuBUPT/archive/2012/02/16/2354132.html

linux中pkill的簡單用法

pkill 和killall 應用方法差不多，也是直接殺死運行中的程序；如果您想殺掉單個進程，請用kill 來殺掉。

必要參數
-f 顯示完整程序
-l 顯示源代碼
-n 顯示新程序
-o 顯示舊程序
-v 與條件不符合的程序
-x 與條件符合的程序

選擇參數
-p<進程號> 列出父進程為用戶指定進程的進程信息
-t<終端> 指定終端下的所有程序
-u<用戶> 指定用戶的程序

應用方法：

#pkill 正在運行的程序名

舉例：

java代碼
[root@localhost beinan]# pgrep -l gaim
2979 gaim
[root@localhost beinan]# pkill gaim

也就是說：

kill 對應的是 PID

pkill 對應的是COMMAND

例如在Ubuntu中強制結束一個已成僵屍的名稱為：firefox，PID為：1603的進程，可以如下操作：

方法一：

（1）ctrl+alt+t，調出終端，輸入 top，然後就可以看到現在系統的進程，是按佔用資源從多到少排列的。

找到要關掉的進程，記下該進程第一列的數字編號(假設是xx)，然後輸入q，退回終端。

（2）輸入：sudo kill xx(對應剛才的編號)。

方法二：

ctrl+alt+t，調出終端，輸入：sudo pkill firefox

範例1： 殺死指定進程

Java代碼
root@snail-hnlinux:~# ps -A //顯示所有進程
PID TTY TIME CMD
1 ? 00:00:03 init
2 ? 00:00:00 kthreadd
3 ? 00:00:00 migration/0
4 ? 00:00:00 ksoftirqd/0
5 ? 00:00:00 watchdog/0
……忽略部分
28382 ? 00:00:00 gvfsd-http
28391 ? 00:07:07 software-center
30467 ? 00:00:31 designer-qt4
30487 ? 00:00:06 gnome-terminal
30488 ? 00:00:00 gnome-pty-helpe
30489 pts/0 00:00:00 bash
30670 ? 00:00:00 debconf-communi
30749 pts/0 00:00:17 gedit
31155 ? 00:00:00 dhclient
31325 ? 00:00:01 sshd
31327 ? 00:00:00 sshd
31400 pts/1 00:00:00 bash
31485 pts/2 00:00:00 bash
3 ? 00:00:00 aptd
31658 pts/1 00:00:00 ps
root@snail-hnlinux:~# pidof sshd //查看與sshd相關進程
31327 31325 2095
root@snail-hnlinux:~# pkill -9 sshd //殺死指定進程

範例2：殺死同義終端下的進程

Java代碼
root@snail-hnlinux:~# pkill -t tty1 //殺死終端1下的所有進程

範例3： 殺死指定用戶進程

Java代碼
root@snail-hnlinux:~# pkill -u hnlinux

範例4：反向選擇

Java代碼
root@snail-hnlinux:~# pkill -vu hnlinux //殺死不屬於hnlinux用戶的所有進程

————————————————
版權聲明：本文為CSDN博主「MrCoderr」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/coderder/article/details/78899823

『貳』 linux中查看進程命令ps aux和ps -ef

Linux下顯示系統進程的命令ps，最常用的有ps -ef 和ps aux。這兩個到底有什麼區別呢？兩者沒太大差別，討論這個問題，要追溯到Unix系統中的兩種風格，System V風格和BSD 風格，ps aux最初用到Unix Style中，而ps -ef被用在System V Style中，兩者輸出略有不同。現在的大部分Linux系統都是可以同時使用這兩種方式的。

ps -ef 是用標準的格式顯示進程的、其格式如下： 

其中各列的內容意思如下 

UID //用戶ID、但輸出的是用戶名 

PID //進程的ID 

PPID //父進程ID 

C //進程棚纖彎佔用CPU的百分比 

STIME //進程啟動到現在的時間 

TTY //該進程在那個終端上運行，若與終端無關，則顯示? 若為pts/0等，則表示由網豎脊絡連接主機進程。 

CMD //命令的名稱和參數

ps aux 是用BSD的格式來顯示、其格式如下： 

同ps -ef 不同的有列有 

USER //用戶名 

%CPU //進程佔用的CPU百分比 

%MEM //佔用內存的百分比 

VSZ //該進程使用的虛擬內存量（KB） 

RSS //該進程佔用的固定內存量（KB）（駐留中頁的數量） 

STAT //進程的狀態 

START //該進程被觸發啟動時間 

TIME //該進程實際使用CPU運行的時間

其中STAT狀態位常見的狀態字元有 

D //無法中斷的休眠狀態（通常 IO 的進程）； uninterruptible sleep (usually IO)不可中斷 

R //正在運行可中在隊列中可過行的； 

S //處於休眠狀態； 

T //停止或被追蹤； traced or stopped 

W //進入內存交換 （從內核2.6開始無效）； 

X //死掉的進程 （基本很少見）； 

Z //僵屍進程；  a defunct (」zombie」) process

< //優先順序高的進程 

N //優先順序較低的進程 

L //有些頁被鏈悶鎖進內存； 

s //進程的領導者（在它之下有子進程）； 

l //多線程，克隆線程（使用 CLONE_THREAD, 類似 NPTL pthreads）； 

+ //位於後台的進程組；

『叄』 linux的ps命令

linux命令ps詳解：

1. 使用許可權：所有使用者（用戶）
   

   使用方式：ps [options] [--help]
   說明：顯示瞬間行程 (process) 的動態
   參數：ps的參數非常多, 在此僅列出幾個常用的參數並大略介紹含義
   -A 列出所有的進程
   -w 顯示加寬可以顯示較多的資訊
   -au 顯示較詳細的資訊
   -aux 顯示所有包含其他使用者的行程

2. 常用參數：

   -A 顯示所有進程（等價於-e）(utility)

   -a 顯示一個終端的所有進程，除了會話引線

   -N 忽略選擇。

   -d 顯示所有進程，但省略所有的會話引線(utility)

   -x 顯示沒有控制終端的進程，同時顯示各個命令的具體路徑。dx不可合用（utility）

   -p pid 進程使用cpu的時間

   -u uid or username 選擇有效的用戶id或者是用戶名

   -g gid or groupname 顯示組的所有進程。

   U username 顯示該用戶下的所有進程，且顯示各個命令的詳細路徑

   -f 全部列出，通常和其他選項聯用。如：ps -fa or ps -fx and so on

   -l 長格式（有F,wchan,C 等欄位）

   -j 作業格式

   -o 用戶自定義格式

   v 以虛擬存儲器格式顯示

   s 以信號格式顯示

   -m 顯示所有的線程

   -H 顯示進程的層次(和其它的命令合用

   e 命令之後顯示環境

   h 不顯示第一行

3. 最常用的方法是ps -aux,然後再ps命令常用用法（方便查看系統進程）

   1）ps a 顯示現行終端機下的所有程序，包括其他用戶的程序

   2）ps -A 顯示所有進程

   3）ps c 列出程序時，顯示每個程序真正的指令名稱，而不包含路徑，參數或常駐服務的標示

   4）ps -e 此參數的效果和指定"A"參數相同

   5）ps e 列出程序時，顯示每個程序所使用的環境變數

   6）ps f 用ASCII字元顯示樹狀結構，表達程序間的相互關系

   7）ps -H 顯示樹狀結構，表示程序間的相互關系

   8）ps -N 顯示所有的程序，除了執行ps指令終機下的程序之外

   9）ps s 採用程序信號的格式顯示程序狀況

   10）ps S 列出程序時，包括已中斷的子程序資料

   11）ps -t<終端機編號> 指定終端機編號，並列出屬於該終端機的程序的狀況

   12）ps u 以用戶為主的格式來顯示程序狀況

   13）ps x 顯示所有程序，不以終端機來區分

   最常用的方法是ps -aux,然後再利用一個管道符號導向到grep去查找特定的進程,然後再對特定的進程進行操作。利用一個管道符號導向到grep去查找特定的進程,然後再對特定的進程進行操作。

『肆』 如何在Linux中查看所有正在運行的進程

查看Linux中所有正在運行的進程 ，可以參考如下方法：

1、通過ps命令的-A或者-e參數來獲取系統中所有的進程，這兩個參數的作用一樣的。

『伍』 ps命令下pthread_create的fork的區別

確實..linux下的線程是假線程..只是和主線程擁有一樣的地告芹址映射表而已..然而POSIX制定了一些源友慎列thread standard..
其中就包括查看進程列表的時候, 相關的一組task_struct應當被展現為列表中的一個節點。並且linux 2.6之後就實現了這個了，所以確實是遍歷task_struct結構體，只是它們並不誠實。

好，其實你想知道的是為啥可以知道task_struct是一組的對不？你可以去看看task_struct結構里有
- pid_t tgid;
//identifier of the thread group leader
然後你就知道了...這個tgid是這個進程主線雹敬程的pid(也可以理解為線程組中第一個創建的線程的pid)

『陸』 linux 子線程執行完成後為什麼使用ps命令依然能夠看到該子線程

ps可以列出主進程和子進程
待x標志列的為主進程

『柒』 如何在Linux中統計一個進程的線程數

1。 使用top命令，具體用法是 top -H加上這個選項，top的每一行就不是顯示一個進程，而是一個線程。
2。 使用ps命令，具體用法是 ps -xH
這樣可以查看所有存在的線程，也可以使用grep作進一步的過濾。
3。 使用ps命令，具體用法是 ps -mq PID
這樣可以看到指定的進程產生的線程數目。
更進一步，其實一些系統監控工具，在本質上也是讀取的系統產生的文件罷了。比如說進程這個事情，
看看這個目錄吧，/proc/5000/ 這裡面有你所有想要的。其實stat代表著當前的一些信息。
使用ps命令來查看進程的時候，進程狀態分別對應的含義如下：
D 不可中斷睡眠 (通常是在IO操作) 收到信號不喚醒和不可運行, 進程必須等待直到有中斷發生
R 正在運行或可運行（在運行隊列排隊中）
S 可中斷睡眠 (休眠中, 受阻, 在等待某個條件的形成或接受到信號)
T 已停止的 進程收到SIGSTOP, SIGSTP, SIGTIN, SIGTOU信號後停止運行
W 正在換頁(2.6.內核之前有效)
X 死進程 (未開啟)
Z 僵屍進程 進程已終止, 但進程描述符存在, 直到父進程調用wait4()系統調用後釋放BSD風格的
< 高優先順序(not nice to other users)
N 低優先順序(nice to other users)
L 頁面鎖定在內存（實時和定製的IO）
s 一個信息頭
l 多線程（使用 CLONE_THREAD，像NPTL的pthreads的那樣）
+ 在前台進程組

『捌』 linux 下查看進程用什麼命令

linux 下查看進程可以使用的命令：

1、ps命令查找與進程相關的PID號：

2、ps a 顯示現行回終端機下的所有程序，包括其他答用戶的程序。

3、ps -A 顯示所有程序。

4、ps c 列出程序時，顯示每個程序真正的指令名稱，而不包含路徑，參數或常駐服務的標示。

5、ps -e 此參數的效果和指定"A"參數相同。

6、ps e 列出程序時，顯示每個程序所使用的環境變數。

7、ps f 用ASCII字元顯示樹狀結構，表達程序間的相互關系。

8、ps -H 顯示樹狀結構，表示程序間的相互關系。

9、ps -N 顯示所有的程序，除了執行ps指令終端機下的程序之外。

10、ps s 採用程序信號的格式顯示程序狀況。

11、ps S 列出程序時，包括已中斷的子程序資料。

12、ps -t<終端機編號> 指定終端機編號，並列出屬於該終端機的程序的狀況。

13、ps u 以用戶為主的格式來顯示程序狀況。

14、ps x 顯示所有程序，不以終端機來區分。

『玖』 Linux中 進程正在運行，ps命令顯示S+

這是由於 cpu 時間片的原因，你看的時候，你的程序正在休眠等待cpu調用中.....你用top命令，你會看到當前進程的變化，有的時候是S 有的時候是R

『拾』 SELinux許可權

在了解SELinux之前，我們先來了解一下Linux的兩種訪問控制策略：DAC和MAC

DAC，自主訪問控制（Discretionary Access control）。系統只提供基本的驗證, 完整的訪問控制由開發者自己控制。
 DAC將資源訪問者分成三類：Owner、Group、Other 。
 將訪問許可權也分成三類：read、write、execute
資源針對資源訪問者設置不同的訪問許可權。訪問者通常是各個用戶的進程，有自己的uid/gid，通過uid/gid 和文件許可權匹配, 來確定是否可以訪問。DAC機制下，每一個用戶進程默認都擁有該用戶的所有許可權。
DAC 有兩個嚴重問題：
 問題一：
 因為Root用戶是擁有所有許可權的，所以DAC對Root用戶的限制是無效的。並且在Linux Kernel 2.1以後，Linux將Root許可權根據不同的應用場景劃分成許多的Root Capabilities, 普通用戶也可以被設置某個Root Capability。普通用戶如果被設置了CAP_DAC_OVERRIDE， 也可以繞過 DAC 限制。
 問題二：
 用戶進程擁有該用戶的所有許可權，可以修改/刪除該用戶的所有文件資源, 難以防止惡意軟體。

可見，DAC 有明顯的缺陷，一旦被入侵，取得Root許可權的用戶進程就可以無法無天，胡作非為，早期android版本就深受其害。

MAC， 強制性訪問控制（Mandatory Access control）。 系統針對每一項訪問都進行嚴格的限制, 具體的限制策略由開發者給出。

Linux MAC 針對DAC 的不足, 要求系統對每一項訪問, 每訪問一個文件資源都需要根據已經定義好了的策略進行針對性的驗證。系統可以針對特定的進程與特定的文件資源來進行許可權的控制。即使是root用戶，它所屬的不同的進程，並不一定能取得root許可權，而得要看事先為該進程定義的訪問限制策略。如果不能通過MAC 驗證，一樣無法執行相關的操作。

與DAC相比，MAC訪問控制的「主體」變成了「進程」而不是用戶。這樣可以限制了Root 許可權的濫用，另外要求對每一項許可權進行了更加完整的細化, 可以限制用戶對資源的訪問行為。

SELinux就是目前最好的MAC機制，也是目前的行業標准。

SELinux，安全增強Linux（Security-Enhanced Linux），是由美國國家安全局(NSA)發起, 多個非營利組織和高校參與開發的強制性安全審查機制（Mandatory Access control，簡稱MAC）。SELinux最早於2000年12月採用GPL許可發布。目前，Linux Kernel 2.6 及以上的版本都已經集成了SELinux。

SELinux 分成三種模式：

Android 5.x及以上強制開啟，因此，disabled(關閉)模式並沒有什麼用了。 通常在調試時，我們會啟用Permissve(寬容模式), 以便盡可能的發現多的問題, 然後一次修正。 在量產時啟用Enfocing mode(強制模式)來保護系統。

查看SELinux模式：adb shell getenforce
設置SELinux模式：adb shell setenforce 1 //0是Permissve，1是Enfocing

SELinux 的訪問控制示意圖：

通常我們開發的過程中，就是配置Subject、Object、Security Policy。

SELinux 給Linux 的所有對象都分配一個安全上下文(Security Context)， 描述成一個標準的字元串。

安全上下文的標准格式： user:role:type[:range]

Security Label 用來綁定被訪問資源和安全上下文，描述它們的對應關系。標准格式為：resource security_context。即：res user:role:type[:range]。這里也可以使用通配符，例如 net.就可以綁定所有以net.開頭的屬性，除此之外，還有類似正則表達式的*、？等等通配符。Security Label 都定義在type_contexts當中，例如file的定義在file_contexts中，service定義在service_contexts中，property定義在property_contexts中。
舉例：
file_contexts:

service_contexts:

查看進程安全上下文： ps -AZ 。例如，查看Settings進程的安全上下文，ps -AZ | grep settings：
  u:r:system_app:s0 system 1381 585 4234504 201072 0 0 S com.android.settings
查看文件安全上下文： ls -Z 。例如，查看文件build.prop的安全上下文：
  u:object_r:system_file:s0 build.prop

Type Enforcement (TE) 是根據Security Context中的 type 進行許可權審查, 審查 subject type 對 object type 的某個class 類型中某種permission 是否具有訪問許可權，是目前使用最為廣泛的MAC 審查機制, 簡單易用。

TE控制語句格式 : rule_name source_type target_type : class perm_set

Type Enforcement規則說明：

舉個例子，logd.te、tombstoned.te中定義的TE規則：
  allow logd runtime_event_log_tags_file:file rw_file_perms;
  dontaudit domain runtime_event_log_tags_file:file { open read };
  auditallow tombstoned anr_data_file:file { append write };
  neverallow logd { app_data_file system_data_file }:dir_file_class_set write;

SELinux 中每一個進程或者文件都對應一個type, 而每一個type 都對應有一個或幾個attribute。所有常見的attribute定義在以下文件中：
  system/sepolicy/public/attributes
  system/sepolicy/prebuilts/api/[build version]/public/attributes
  system/sepolicy/prebuilts/api/[build version]/private/attributes
其中的[build version]即為android版本號，例如android O為28.0。常見的attribute定義：

Type對應一個或者幾個attribute，Type的定義格式：
  type type_name, attribute1, attribute2；
Type的定義通常分散在各個te文件中。例如，常用普通文件的type定義在file.te中：

SEAndroid對於不同的資源類型，定義了不同的Class。比如普通的file、socket等等，比如SELinux 使用的security, 比如針對每個process 參數的process 等定義相關的class。這些class，每一個class 都有相對應的permissions。 比如file 就有 read, write, create, getattr, setattr, lock, ioctl 等等. 比如process 就有fork, sigchld, sigkill, ptrace, getpgid, setpgid 等等。這些相關的class, 以及他們具有那些Permissions都定義在以下文件中：
  system/sepolicy/private/access_vectors
  system/sepolicy/reqd_mask/access_vectors
  system/sepolicy/prebuilts/api/版本號/private/access_vectors
例如：

定義完之後，在以下對應的security_classes 文件中聲明定義的classes。
  system/sepolicy/private/security_classes
  system/sepolicy/reqd_mask/security_classes
  system/sepolicy/prebuilts/api/版本號/private/security_classes
例如：

注意，Classes 和Permissions的定義與Kernel 中相關API是強相關的，普通用戶嚴禁修改。

在SELinux 中, 我們通常稱一個進程是一個domain, 一個進程fork 另外一個進程並執行(exec) 一個執行檔時, 我們往往會涉及到domain 的切換. 比如init 進程, SELinux 給予了它很大的許可權, 而它拉起的服務, 我們要限制這個服務的許可權，於是就涉及到從一個domain 切換到另外一個domain, 不然默認就使用init 進程的domain.

在SELinux 裡面有專門的一條語法: type_transition statement.
在准備切換前我們先要確保有相關的許可權操作：

如下面的demo, init 拉起apache 並且切換到 apache 的domain.
(1). 首先，你得讓init_t域中的進程能夠執行type為apache_exec_t的文件
  allow init_t apache_exec_t : file {read getattr execute};
(2). 然後，你還得告訴SELinux，允許init_t做DT切換以進入apache_t域
  allow init_t apache_t : process transition;
(3). 然後，你還得告訴SELinux，切換入口（對應為entrypoint許可權）為執行apache_exec_t類型 的文件
  allow apache_t apache_exec_t : file entrypoint;
(4).最後，Domain Transition
  type_transition init_t apache_exec_t : process apache_t;

可以看到，整個domain切換過程寫起來非常麻煩。因此，Google 為了使用方便, 在system/sepolicy/public/te_macros 文件中定義了宏：

我們可以使用這些宏來完成domain切換。

舉例：
kernel啟動init進程切換domain:
  domain_auto_trans(kernel, init_exec, init)
init啟動netd、vold、zygote、installd切換domain:
  init_daemon_domain(netd)
  init_daemon_domain(vold)
  init_daemon_domain(zygote)
  init_daemon_domain(installd)

一個進程創建在一個目錄下創建文件時, 默認是沿用父目錄的Security Context, 如果要設置成特定的Label, 就必須進行Object Transitions.
同樣是使用：type_transition statement.
對應的必須有兩個前提條件:

下面是一個demo, ext_gateway_t 這個domain 在類型為in_queue_t 的目錄下，創建類型為 in_file_t 的文件.

(1). 首先，你得讓ext_gateway_t 對in_queue_t 目錄具備訪問許可權
  allow ext_gateway_t in_queue_t : dir { write search add_name };
(2). 然後，你還得告訴SELinux，允許ext_gateway_t 訪問in_file_t的文件
  allow ext_gateway_t in_file_t : file { write create getattr };
(3).最後，Object Transition
  type_transition ext_gateway_t in_queue_t : file in_file_t;

同樣的，為了方便使用，Google 也在system/sepolicy/public/te_macros 文件中定義了宏:

使用舉例：
  file_type_auto_trans(factory, system_data_file, factory_data_file)

android O 以前sepolicy 集中放在boot image 。前面提到SELinux在Android的主要變更歷史時，有提到android O 開始，Google將system image 和 vendor image 分離。因此，sepolicy 也相應的被分離存放到system image 以及 vendor image。與system 相關的sepolicy 就存放system image, 與SoC vendor 相關的sepolicy 就存放在vendor image。

對於原生AOSP，Google 設定了不同的存放目錄, 以便進行分離, 以Google 默認的sepolicy 為例，sepolicy主目錄為 /system/sepolicy，我們主要關注三個子目錄：

對於不同的平台，不同平台廠商也設定了不同的存放目錄，以MTK平台為例：
首先，根據不同的platform共用sepolicy、platform獨有、project獨有，分為：

對應的，不同版本會導入不同目錄下的sepolicy配置

以mt6763平台為例，導入時：
[common] 路徑為：/device/mediatek/sepolicy
[platfrom] 路徑為：/device/mediatek/mt6763/sepolicy/
具體的定義在BoardConfig.mk文件中:

然後，basic、bsp、full又可以主要細分為：

Google 在system/sepolicy 中定義了相關的neverallow 規則, 對SELinux Policy 的更新進行了限制, 以防止開發者過度開放許可權，從而引發安全問題。並且還會通過CTS測試檢測開發者是否有違法相關的規則。

因此，我們需要注意以下幾點：

出現SELinux Policy Exception時常見的兩種解決方案：

(1). 修改對應節點的SELinux Security Label, 為特定的Subject，如system_app、platform_app、priv_app，例如Settings，SystemUI等內置APP開啟許可權, 但嚴禁為untrsted app 開啟許可權。
(2). 通過system server service 或者 init 啟動的service 讀寫操作, 然後app 通過binder/socket 等方式連接訪問. 此類安全可靠, 並且可以在service 中做相關的安全審查, 推薦這種方法.

情景: 定義由 init 進程啟動的service, factory, 其對應的執行檔是 /vendor/bin/factory。

(1). 在device/mediatek/mt6763/sepolicy/basic/non_plat 目錄下創建一個factory.te , 然後將te文件加入編譯，如放到這種指定目錄下不需要額外配置，sytem/sepolicy/Android.mk中定義的build_policy函數會遍歷指定目錄導入te文件。

(2). 在factory.te 中定義factory類型，init 啟動service 時類型轉換,
  type factory, domain;
  type factory_exec, exec_type, file_type, vendor_file_type;
  init_daemon_domain(factory)

(3). 在file_contexts中綁定執行檔
  /(system/vendor|vendor)/bin/factory u:object_r:factory_exec:s0

(4). 根據factory需要訪問的文件以及設備, 定義其它的許可權在factory.te 中.
  #Purpose: For key and touch event
  allow factory input_device:chr_file r_file_perms;
  allow factory input_device:dir rw_dir_perms;

情景: 添加一個自定義的system property： persist.demo，並為platform_app設置讀寫許可權

(1). 在property.te中定義system property類型
  type demo_prop, property_type

(2). 在property_contexts中綁定system property的安全上下文。
  persist.demo u:object_r:demo_prop:s0

(3). 在platform_app.te 中新增寫許可權，可以使用set_prop宏。
  set_prop(platform_app, demo_prop)

(4). 在platform_app.te 中新增讀許可權，可以get_prop 宏。
  get_prop(platform_app, demo_prop)

情景: 有一個設備節點/dev/demo，有一個platform_app進程需要讀寫這個設備節點。

(1). 在device.te中定義device 類型
  type demo_device dev_type;

(2). 在 file_contexts中綁定demo_device
  /dev/demo u:object_r:demo_device:s0

(3). 在platform_app.te中，允許platform_app使用demo device 的許可權
  allow platform_app demo_device:chr_file rw_file_perms;

情景: 有一個擴展的系統服務demo_service供APP調用。

(1). 在service.te 中定義service 類型
  type demo_service, app_api_service, system_server_service, service_manager_type;

(2). 在service_contexts 中綁定service
  demo u:object_r:demo_service:s0

(3). 在frameworks/base/core/java/android/content/Context.java中定義服務常量
  public static final String DEMO_SERVICE = "demo";

(4). 在frameworks/base/core/java/android/app/SystemServiceRegistry.java中，參照其它系統服務注冊demo_service

(5). 在frameworks/base/services/java/com/android/server/SystemServer.java中，啟動DemoService，添加到service_manager進行管理。

(6). 最後一步，參考其它系統服務，實現DemoManager、DemoService，並定義如IDemoService等等的AIDL介面。

情景: 一個native service 通過init 創建一個socket 並綁定在 /dev/socket/demo, 並且允許某些process 訪問.

(1). 在file.te中定義socket 的類型
  type demo_socket, file_type;

(2). 在file_contexts中綁定socket 的類型
  /dev/socket/demo_socket u:object_r:demo_socket:s0

(3). 允許所有的process 訪問，使用宏unix_socket_connect(clientdomain, socket, serverdomain)
  unix_socket_connect(appdomain, demo, demo)

(1). 在device/mediatek/mt6763/sepolicy/basic/non_plat目錄下創建一個demo.te。

(2). 在demo.te 中定義demo 類型，init 啟動service 時類型轉換。並可以根據demo 需要訪問的文件以及設備, 定義其它的許可權在demo.te 中。
  type demo, domain;
  type demo_exec, exec_type, file_type;
  init_daemon_domain(demo)

(3). 綁定執行檔 file_context 類型
  /vendor/bin/demo u:object_r:demo_exec:s0

(4). 創建demo的入口執行檔demo_exec、並配置相應的許可權。

(1). 將SELinux 調整到Permissive 模式復測
使用eng/userdebug 版本，adb shell setenforce 0 將SELinux 模式調整到Permissive 模式，然後復測。如果還能復現問題，則與SELinux 無關； 如果原本很容易復現, 而Permissive mode 不能再復現, 那麼就可能與SELinux相關。

(2). 查看LOG 中是否有標準的SELinux Policy Exception.
在Kernel LOG / Main Log 中查詢關鍵字 "avc: denied" 看看是否有與目標進程相關的SELinux Policy Exception, 並進一步確認這個異常是否與當時的邏輯相關。

一般情況我們在符合Google sepolicy策略及neverallow策略的前提下，根據LOG中的內容，需要什麼許可權就加什麼許可權。例如LOG：
2020-03-27 14:11:02.596 1228-1228/com.android.systemui W/FaceIdThread: type=1400 audit(0.0:481): avc: denied { read } for name="als_ps" dev="tmpfs" ino=10279 scontext=u:r:platform_app:s0:c512,c768 tcontext=u:object_r:als_ps_device:s0 tclass=chr_file permissive=0

LOG說明如下：

一般我們需要重點關注的是四個：permission、source type、target type、target class

根據這四個就可以配置出的所需要的selinux許可權：
   allow [source type] [target type]: [target class] [permission]
例1：
03-27 03:45:22.632 2958 2958 W Camera: type=1400 audit(0.0:314): avc: denied { read } for name="u:object_r:graphics_debug_prop:s0" dev="tmpfs" ino=2649 scontext=u:r:platform_app:s0:c512,c768 tcontext=u:object_r:graphics_debug_prop:s0 tclass=file permissive=0

解決方案：
按正常的套公式，應該是這樣修改platform_app.te，增加：
  allow platform_app graphics_debug_prop:file r_file_perms;
這里我們利用system/sepolicy/te_macros中定義的宏get_prop：

更多相關的宏定義請參考：system/sepolicy/public/te_macros。
所以最終簡化後，修改platform_app.te，增加：
  get_prop(platform_app, graphics_debug_prop)

例2：
03-27 14:11:02.596 1228-1228/com.android.systemui W/BackThread: type=1400 audit(0.0:481): avc: denied { read } for name="als_ps" dev="tmpfs" ino=10279 scontext=u:r:platform_app:s0:c512,c768 tcontext=u:object_r:als_ps_device:s0 tclass=chr_file permissive=0

解決方案：
修改platform_app.te增加：
  allow platform_app als_ps_device:chr_file r_file_perms;

(1). 不符合neverallow規則或者修改了neverallow規則
編譯報錯：
  neverallow check failed at xxx
CTS測試項failed：
  android.cts.security.SELinuxNeverallowRulesTest#testNeverallowRulesXXX
這類問題在android O vendor和system分離之後，尤其容易出現。基本上這類問題都是因為修改或者增加的te配置不符合neverallow規則，導致編譯報錯。而為了解決編譯報錯，又修改了neverallow規則，最終在跑CTS時，沒法通過相關的測試項。

解決思路：

(2). init進程fork新進程沒有做domain切換
CTS測試項failed：
  android.security.cts.SELinuxDomainTest # testInitDomain

解決思路：
fork進程時，參考3.4節中做domain切換。

本文主要參考了MTK-Online的Quick-start中《SELinux 問題快速分析》的內容，感謝原作者們的辛勤付出。另外，結合源碼和自身開發實踐，增加了一些自身理解和實踐內容。