Linux 安全基础--用户(用户组)

1.与一个进程相关联的用户ID和组ID

与每一个进程相关联的ID有六个或更多，三对，分别是：

(1) 实际用户/组ID（对应登录用户）

(2) 有效用户/组ID、添加组ID（文件存取许可检查）

(3) 保存设置-用户/组ID（由exec函数保存）

通过 cat /proc/pid/status/ 查看：

Uid:    0       0       0       0

Gid:    0       0       0       0

解释:

第一列数字(RUID):实际用户ID,指的是进程执行者是谁.

第二列数字(EUID):有效用户ID,指进程执行时对文件的访问权限.

第三列数字(SUID):保存设置用户ID,作为effective user ID的副本,在执行exec调用时后能重新恢复原来的effectiv user ID.

第四列数字(FSUID):目前进程的文件系统的用户识别码.一般情况下,文件系统的用户识别码(fsuid)与有效的用户识别码(euid)是相同的.

Groups: 0

解释:

这里的groups表示启动这个进程的用户所在的组.

我们当前的用户test,现在在两个组(1000,2000)里面,如下:

id

uid=1002(test) gid=1002(nagcmd) groups=1000(chenkuo),1002(nagcmd)

2.文件访问权限

st_mode值也包含了文件的访问权限。

owner | group  | other

3.文件访问权限的测试

进程每次打开、创建、删除一个文件， 内核都会进行访问权限测试：【按顺序执行】

需要文件的性质(uid , gid)和进程的性质(st_uid, st_gid)共同决定：

(1) 进程有效用户id是0；

(2) 进程的有效用户ID= 文件所有者ID， （即使进程拥有文件） ，需要所有者适当的访问权限位被设置；

(3) 进程的有效用户ID 或附加组ID 等于 文件组ID， 需要所有者适当的访问权限位被设置

(4)  若其他用户适当的访问权限位被设置。

4..umask

与每个进程相关联的文件模式创建屏蔽字。

进程创建一个新文件 或新目录，对于任何文件模式屏蔽字中为1 的位，在文件mode中相应的位一定被关闭。

5.新文件和新目录的所有权

新文件的用户ID设置为进程的有效用户ID。关于组ID：下面之一

(1) 新文件的组ID可以是进程的有效组ID

(2)  新文件的组ID可以是它所在目录的组ID

6.更改用户ID和组ID

在LINUX 特权是基于用户和组ID的。

1. 增加特权

2. 降低其特权或者阻止对某些资源的访问时

  least privilege , 最小特权模型。

int setuid(uid_t uid);

关于谁能够更改ID，有若干规则。

(1)  进程具有超级用户特权

(2) 进程没有超级用户特权， 但是UID=实际用户ID 或保存的设置用户ID， 则setuid 只能将有效用户ID设置为uid。

内核维护的3个有用户ID， 还需要下列：

(1)  只有超级用户可以改变实际用户ID

(2)  仅当程序设置了用户ID位， exec函数才会设置用户用户ID。

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

组被用于将若干用户分到不用的项目组或者部门中去， 这种机制允许同组的各个成员之间共享资源， 例如文件。

----------------------------------------

无死角理解保存设置用户ID，设置用户ID位，有效用户ID，实际用户ID，死角保存设置

最近在理解保存设置用户ID时，遇到一些问题，但是发现网上都没能把这个问题说清楚，通过自己的思考和查找资料，终于明白了，现在分享在这里共大家交流学习，如果有不正确的地方，欢迎指正

1，基本概念：

实际用户ID（RUID）：用于标识一个系统中用户是谁，一般是在登录之后，就被唯一确定的，就是登陆的用户的uid

有效用户ID（EUID）：用于系统决定用户对系统资源的权限。也就是说当用户做任何一个操作时，最终看它有没有权限，都是在判断有效用户ID是否有权限，如果有，则OK，否则报错不能执行。在正常情况下，一个用户登录之后（我们假设是A用户），A用户的有效用户ID和实际用户ID是相同的，但是如果A用户在某些场景中想要执行一些特权操作，而上面我们说到用户的任何操作，LINUX内核都是通过检验有效用户ID来判断当前执行这个操作的用户是否具有权限，显然是特权操作，A用户没有权限，所以A用户就只能通过一定的手段来修改当前的有效用户ID使其具有执行特权操作的权限。这里说明了下面为什么我们需要修改有效用户ID，就是想再某一时刻能够执行一些特权操作。下面在举例说明。

设置用户ID位：用于对外的权限的开发，它的作用是我们如何去修改有效用户ID，在后面的例子中在展开。

保存设置用户ID（SUID）：是有效用户ID副本，既然有效用户ID是副本，那么它的作用肯定是为了以后恢复有效用户ID用的。

2，改变三个用户ID的方法

下面这幅图给出了改变实际用户ID，有效用户ID和保存设置用户ID的方法

                               

3，实例1，如何在权限不够的情况下执行特权权限，也就是更改我们的有效用户ID。

我们知道用户的密码都是存放在/etc/shadow文件下，我们看下这个文件的权限root@debian:~# ls -l /etc/shadow
-rw-r----- 1 root shadow 8013 Sep  8 14:58 /etc/shadow
假如我是一个普通用户，显然我是可以修改我的密码的，通过passwd命令，无可厚非。自己修改自己的密码肯定是被允许的。但是仔细想想你会发现不对啊，我作为一个普通用户登录后，我的实际用户ID和有效用户ID都是我自己的UID。从上面可以看出，显然我不具有修改/etc/shadow文件的权限，那我执行passwd命令时怎么改我的密码的呢？在上面1，基本概念中我们知道决定我们权限的是执行操作时的有效用户ID，所有我们在执行passwd命令时，我们的有效用户ID肯定被修改了。OK，我们看下面：root@debian:~# ls -l /usr/bin/passwd 
-rwsr-xr-x 1 root root 43280 Feb 16  2011 /usr/bin/passwd我们看到了一个s，对的，它就是我们的保存设置用户ID位，上面我们说过这个位的作用就是修改有效用户ID，那我们来看看他是如何修改执行passwd命令时的有效用户ID的。
首先我们看下命令执行的过程，当普通用户执行passwd命令时，shell会fork出一个子进程，此时进程有效用户ID还是普通用户ID，然后exec程序执行/usr/bin/passwd。通过上面的表我们会知道，exec发现/usr/bin/passwd有SUID位，于是会把进程的有效用户ID设成设置成文件用户ID，显然就是root,   此时这个进程都获得了root权限, 得到了读写/etc/shadow文件的权限, 从而普通用户可完成密码的修改。exec进程退出后会恢复普通用户的EUID为普通用户ID.这样就不会使普通用户一直拥有root权限。
这就是我们设置用户ID位的作用，它的存在就是为了普通用户在某些需要特权权限时，去临时的改变有效用户ID而获得特权权限。但是你可能有疑问，为什么我们不用setuid()直接修改呢？何苦绕这么大的弯子。但是如果可以使用setuid()来直接修改有效用户ID来获得特权权限，那么我们的特权权限就会不可控了。这违背了最小权限模型。所以我们Linux特意将setuid设置成在非特权用户下面，有效用户ID只能设置成为实际用户ID和保存设置用户ID，而保存设置用户ID又是来自于有效用户ID的复制，而有效用户ID只能是实际用户ID或者文件所有者ID（在你设置了保存设置用户ID情况下才可以）。这样你就没法将有效用户ID设置成随意值，所以对普通用户创建的任何文件如果没有得到超级用户的授权，那么无论他怎么编写代码来设置自己的有效用户ID，或者设置保存用户ID位，由于你这个可执行文件是你自己编写的，所有你的权限更本没有得到实质性的改变。这里也就是说只有root自己创建的文件才具有这样的特权权限。这样是不是很好的保护了操作系统对权限的控制呢？

4，实例2，保存设置用户ID的作用

那么保存设置用户ID的作用又是什么呢？既然保存用户ID是有效用户ID的副本，那么肯定是为在某个时刻用于恢复我们的有效用户ID。这样就可能实现我们的用户权限的切换。例如：man（这是AUP上面的例子，当然实际linux上好像不是这样实现，不过为了便于说明，还是直接使用了这个例子）
        man程序的实际用户ID是man，有效用户ID也是man
1、首先我们的进程要执行man命令，所以exec发现/usr/bin/man已经设置了用户ID位，于是进程的有效用户ID给改了/usr/bin/man的拥有者，即改成man了，并且复制了man给保存设置用户ID，然后我们就可以顺利执行man命令了。
此时我们进程的ID：
实际用户ID = 我们的用户ID
有效用户ID = man（为了执行man命令）
  保存的设置用户ID = man（exec设置的）man程序访问需要配置文件和手册页，这些文件时名为man的用户所有的，因为有效用户ID是man,所有我们的操作得以顺利的被执行了。2，我们的进程要求man执行其他命令（这里不仅我们要执行man命令，我们还会让man代表我们执行一些命令），但是现在我们的有效ID是man，所以需要更改有效ID为我们进程的实际ID，调用setuid（getuid（））函数,由于我不是超级用户，所以，
实际用户ID = 我们的用户ID
有效用户ID = 我们的用户ID（setuid改的）
保存的设置用户ID = man现在man进程是以我们的用户ID而运行的，这就意味着能访问的只有我们通常可以访问的，而没有额外的权限，
3，当man完成代替我们执行的命令后，我们当然要回到我们之前有效用户ID，也就是man,此时我们的保存设置用户ID这个副本就开始发挥它的作用了，我们只需要setuid(geteuid());即可，通过了这个有效用户ID的副本保存设置用户ID，我们的有效用户ID才能在man->uid->man这样的切换。如果没有保存设置用户ID这个副本，显然，我们是没有办法在man程序代替我们执行完命令之后，在将有效用户ID设置成man的。

用户ID是什

就是计算机程序为来访用户做的唯一标识，可以区分和记录不同用户访问的各种轨迹，通常我们浏览任何一个网站或网页都会有一个ID只是，这种ID保存的时间可以设置和调整，一般当我们离开某个页面ID就消失。但是在一些会员注册的网站ID可以记录到数据库中，长久保存。
 

notes 为何我更换用户ID后 显示不了邮件内容，说是没有阅读数据库权限 在哪设置哦？

原因：Notes中有个概念叫做场景（英文原版叫Location），这个场景会设置一些用户信息，比如用户名，用户ID，用户的邮箱服务器及邮箱位置，OK，理解这个概念后，如果你仅仅更换了ID，那么当你使用Notes自带的一些便捷的打开邮箱的方法的时候，它还是在找原先的场景里面的设置，也就是之前的用户的邮箱位置，这就是为什么会提示没有权限了，解决的方法就是为新的ID设置一个新的场景，或者编辑旧的场景，场景的切换和编辑在Notes的右下方，自己试着改一下，如果不会再说