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 问题快速分析》的内容，感谢原作者们的辛勤付出。另外，结合源码和自身开发实践，增加了一些自身理解和实践内容。