Linux的用户在登录(login)之后，就带有一个用户身份(user ID, UID)和一个组身份(group ID, GID)。

一般来说，Linux的用户信息保存在/etc/passwd中，组信息保存在/etc/group中，文件的每一行代表一个用户/组。早期的Linux将密码以名码的形式保存在/etc/passwd中，而现在则多以暗码(也就是加密之后的形式)的形式保存在/etc/shadow中。将密码存储在/etc/shadow中提高了密码的安全性，因为/etc/passwd允许所有人查看，而/etc/shadow只允许root用户查看。

在Linux中，用户的指令是在进程的范围内进行的。当我们向对某个文件进行操作的时候，我们需要在进程中运行一个程序，在进程中对文件打开，并进行读、写或者执行的操作。因此，我们需要将用户的权限传递给进程，以便进程真正去执行操作。例如我们有一个文件a.txt, 文件中为一个字符串:

我以用户Vamei的身份登录，并在shell中运行如下命令：

$cat a.txt

整个运行过程以及文件读取如下: 我们可以看到，整个过程中我们会有两个进程，

图中的fork, exec, PID可参看Linux进程基础。第二个进程总共对文件系统进行了两次操作，一次是执行(x)文件/bin/cat，另外一次是读取(r)文件a.txt。使用$ls -l 查看这两个文件的权限:

/bin/cat让所有用户都享有执行的权利，而Vamei作为a.txt的拥有者，对a.txt享有读取的权利。

在进行这两次操作的时候，尽管用户Vamei拥有相应的权限，但我们发现，真正做工作的是进程9913。我们要让这个进程得到相应的权限。实际上，每个进程会维护有如下6个ID：

其中，真实身份是我们登录使用的身份，有效身份是当该进程真正去操作文件时所检查的身份，存储身份较为特殊，我们等一下再深入。当进程fork的时候，真实身份和有效身份都会复制给子进程。大部分情况下，真实身份和有效身份都相同。当Linux完成开机启动之后，init进程会执行一个login的子进程。我们将用户名和密码传递给login子进程。login在查询了/etc/passwd和/etc/shadow，并确定了其合法性之后，运行(利用exec)一个shell进程，shell进程真实身份被设置成为该用户的身份。由于此后fork此shell进程的子进程都会继承真实身份，所以该真实身份会持续下去，直到我们登出并以其他身份再次登录(当我们使用su成为root的时候，实际上就是以root身份再次登录，此后真实身份成为root)。

每个进程为什么不简单地只维护真实身份，却选择费尽麻烦地去维护有效身份和存储身份呢？这牵涉到Linux的“最小特权”(least priviledge)的原则。Linux通常希望进程只拥有足够完成其工作的特权，而不希望赋予更多的特权给它。从设计上来说，最简单的是赋予每个进程以super user的特权，这样进程就可以想做什么做什么。然而，这对于系统来说是一个巨大的安全漏洞，特别是在多用户环境下，如果每个用户都享有无限制的特权，就很容易破坏其他用户的文件或者系统本身。“最小特权”就是收缩进程所享有的特权，以防进程滥用特权。

然而，进程的不同阶段可能需要不同的特权。比如一个进程最开始的有效身份是真实身份，但运行到中间的时候，需要以其他的用户身份读入某些配置文件，然后再进行其他的操作。为了防止其他的用户身份被滥用，我们需要在操作之前，让进程的有效身份变更回来成为真实身份。这样，进程需要在两个身份之间变化。

系统资源分派：

简单概括安全模型为linux系统需要知道登录验证用户的身份，登录用户基于身份会有不同的权限访问系统文件，同时也会有审计功能来知道登录用户在系统什么时间做了什么。

linux中每个用户是通过UID来唯一标识的

root管理员UID为0

linux中可以将一个或者多个用户加入用户组中，用户组是通过GID来唯一标识的。

管理员组 root 0

普通组：

用户的主组：用户必须属于一个切治愈后一个驻足，默认创建用户时会自动创建和用户名的组，做为用户的主要组，由于此组中只有一个用户，称为私有组。

用户附加组：一个用户可以属于0个或多个辅助组。

能不能访问资源，是由执行命令者的身份决定的 Linux安全上下文Context：运行中的程序，即进程 (process)，以进程发起者的身份运行，进程所能够访问资源的权限取决于进程的运行者的身份 比如：分别以root 和ZP1015的身份运行/bin/cat /etc/shadow ，得到的结果是不同的，资源能否能被访问，是由运行者的身份决定，非程序本身。要想访问资源先检查权限，没权限先赋权！ ZP1015 用户可以查看passwd但是无法查看shadow文件

在Unix系统中，特权以及访问控制是基于用户ID和组ID的。当程序需要增加特权，或者需要访问当前并不允许访问的资源时，我们需要更换自己的用户ID或组ID，使得新ID具有合适的特权或访问权限。与此类似，当程序需要降低其特权或阻止对某些资源的访问时，也需要更换用户ID或组ID，新ID不具有相应特权或访问这些资源的能力。

一般而言，在设计应用时，我们总是试图使用最小特权（least privilege)模型。依照此模型，我们的程序应当只具有为完成给定任务所需的最小特权。这降低了由恶意用户试图哄骗我们的程序以未料的方式使用特权造成的安全性风险。

可以用setuid函数设置实际用户ID、有效用户ID。与此类似，可以用setgid函数设置实际组ID和有效组ID。

关于谁能更改ID有若干规则。现在优先考虑更改用户ID的规则（关于用户ID我们所说明的一切都适用于组ID）：

若进程具有超级用户权限，则setuid函数将实际用户ID、有效用户ID以及保存的设置用户ID(saved set-user-ID)设置为UID。

若进程没有超级用户特权，但是uid等于实际用户ID或保存的设置用户ID，则setuid只将有效用户ID设置为uid。不更改实际用户ID和保存的设置用户ID。

如果上面两个条件都不满足，则errno设置为EPERM，并返回-1。

关于内核所维护的3个用户ID，还需要注意以下几点：

只有超级用户进程可以更改实际用户ID。通常，实际用户ID是在用户登录时，由login程序设置的，而且绝不会改变它。因为login是一个超级用户进程，当它调用setuid时，设置所有3个用户ID。

仅当对程序文件设置了设置用户ID位时，exec才设置有效用户ID。如果设置用户ID位没有设置，exec函数不会改变有效用户ID，而将维持其现有值。任何时候都可以调用setuid，将有效用户ID设置为实际用户ID或保存的设置用户ID。自然地，不能将有效用户ID设置为任一随机值。

保存的设置用户ID是由exec复制有效用户ID而得到的。如果设置了文件的设置用户ID位，则在exec根据文件的用户ID设置了进程的有效用户ID以后， 这个副本就被保存起来。

下表总结了更改这3个用户ID的不同方法： 注意： getuid和geteuid函数只能获得实际的用户ID和有效公户ID的当前值。我们没有可移植的方法去获得保存的设置用户ID的当前值。

历史上，BSD支持setreuid函数，其功能是交换实际用户ID和有效用户ID的值。

规则很简单：一个非特权用户总能交换实际用户ID和有效用户ID。这就允许一个设置用户ID程序交换成普通的用户权限，以后又可再次交换回设置用户ID权限。POSIX.1引进了保存的设置用户ID特性后，其规则也相应加强，它允许一个非特权用户将其有效用户ID设置为保存的设置用户ID。

POSIX.1包含了两个函数seteuid和setegid。它们类似于setuid和setgid，但只能更改有效用户ID和有效组ID。

下图给出了上面所述的更改3个不同用户ID的各个函数：

1、CA-TA访问控制，我们可以限定哪些GID下进程可以访问TA的服务。毕竟GID修改需要root权限，我们可以防止普通用户滥调用安全下服务，毕竟UID可以作为进程的身份唯一标识。