Home Diary Blog Photo Community Open Source
〖 实际用户ID,有效用户ID和设置用户ID 〗
Visits: 283
zane

Topics: 28
Posts: 31
No. 1
转自:https://blog.csdn.net/demiaowu/article/details/39370355

最近在理解保存设置用户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的。
2018-07-16 16:31:17
zane

Topics: 28
Posts: 31
No. 2

转自:https://blog.csdn.net/u011412619/article/details/44002807

实际用户ID,有效用户ID和设置用户ID

    看UNIX相关的书时经常能遇到这几个概念,但一直没有好好去理清这几个概念,以致对这几个概念一直一知半解。今天好好区分了一下这几个概念并总结如下。说白了这几个UID引出都是为了系统的权限管理。

 

    下面分别用RUID, EUID,SUID来表示实际用户ID,有效用户ID,设置用户ID。另外用户ID是个整型数,为了说明方便真接使用了用户名来代表不同的UID。先解释一下这几个ID的作用:

RUID, 用于在系统中标识一个用户是谁,当用户使用用户名和密码成功登录后一个UNIX系统后就唯一确定了他的RUID.

EUID, 用于系统决定用户对系统资源的访问权限,通常情况下等于RUID。

SUID,用于对外权限的开放。跟RUID及EUID是用一个用户绑定不同,它是跟文件而不是跟用户绑定。

 

    说明SUID的时候很多书都简略的提了一下passwd这个程序,下面就拿这个例子来分析。我们知道linux系统的密码都存在了/etc/shadow这个文件里。这个文件是如此的重要,在做任何修改之前最好先备份一下。查看/etc/shadow文件的属性如下:

 

[root@localhost ~]# ll /etc/shadow

-r-------- 1 root root 1144 Jul 20 22:33 /etc/shadow

 

从上可以看出/etc/shadow文件是一个属于root用户及root组的文件,并且只有EUID为root的用户具有读的权限,其它所有EUID都没有任何权限。当你在steve用户(EUID此时也为steve)的shell下试图用vim打开这个文件时会提示权限不允许。至于连root用户也只有读的权限我猜是为了不鼓励root用户使用vim类的编辑器去直接修改它,而要采用passwd命令来修改这个文件。如果你非要直接修改它,那么你可以使用chmod命令修改为属性为root可写,然后就可以修改了。

 

    用过UNIX系统的人都知道,任何一个用户都可以使用passwd这个命令来得新设定自己的密码。但从上面已经知道,非root用记是无法读这个文件的,那么普通用户是如何做到修改这个文件的呢?我们知道passwd这个命令实际执行的程序是/usr/bin/passwd, 查看这个文件属性如下:

 

-r-s--x--x 1 root root 21944 Feb 12  2006 /usr/bin/passwd;

 

对应文件存取标志的s位就是通常说的SUID位,另外可以看到所有用户都有执行的这个程序权力。当steve用户执行passwd命令的时候。Shell会fork出一个子进程,此时进程的EUID还是steve,然后exec程序/usr/bin/passwd。exec会根据/usr/bin/passwd的SUID位会把进程的EUID设成root,   此时这个进程都获得了root权限, 得到了读写/etc/shadow文件的权限, 从而steve用户可完成密码的修改。 exec退出后会恢复steve用户的EUID为steve.这样就不会使steve用户一直拥有root权限。

 

我们可以测试一下,用root用户把/usr/bin/passwd的SUID位去掉,如下:

[root@localhost ~]# ll /usr/bin/passwd 

-r-s--x--x 1 root root 21944 Feb 12  2006 /usr/bin/passwd

[root@localhost ~]# chmod u-s /usr/bin/passwd

[root@localhost ~]# ll /usr/bin/passwd       

-r-x--x--x 1 root root 21944 Feb 12  2006 /usr/bin/passwd

 

然后steve用户用命令passwd去更新密码会提示如下错误:

[steve@localhost ~]$ passwd

Changing password for user steve.

Changing password for steve

(current) UNIX password:

passwd: Authentication token manipulation error

[steve@localhost ~]$

这就是因为/usr/bin/passwd程序的SUID去掉后,steve用户虽然可以执行该程序,但因为/usr/bin/passwd/的SUID没有设置,这样exec后进程的EUID仍为steve的原因。

 

    也许有人会发现root用户却仍可以使用该用命修改密码,那是因为root用户本身的EUID时就是root (也有可能只要发现是RUID是root就不检查EUID了,直接可读写,root就是老大嘛), 可以读取密码文件。

 

另外也许有人会发现普通的文件文件普通的文本文件会也可以设置SUID位, 但这是没有意义的,因为文件文件没有地方执行seteuid()的系统调用来改变当用用户的EUID。

 

最后,这里的对用户ID的规则同样也适用了组ID。

2018-07-16 16:25:49