解释一:
摘要:最近看APUE时为这几个ID困扰了很久,查找了很多资料后,终于感觉比较清晰了。先记在这里。或许还有些理解上的偏差,后续更正。本文主要讲述这几种ID的区别和联系。
实际用户ID:有的文章中将其称为真实用户ID,这个ID就是我们登陆unix系统时的身份ID。
有效用户ID:定义了操作者的权限。有效用户ID是进程的属性,决定了该进程对文件的访问权限。
文件的访问权限包括读写和执行。判断某个进程对文件有何权限时,内核会将非超级用户进程的有效ID与文件的所有者ID进行比较,当然,也可能需要比较有效组ID,这关系到具体的权限测试方法,先不在这里说明。而超级用户创建的进程是允许访问整个文件系统的。它的有效ID等于0。不过,这里还有一点需要说明的是,仅仅有合适的有效ID,还不一定就能获得所有或者部分权限。你需要得到被访问文件的允许,这就是文件访问权限位(用户读、用户写、组读等)的责任了。
这里又牵涉到一个“ID”,即文件的所有者ID。文件的所有者ID是什么呢?创建文件是由某用户的进程实现的吧?所以在创建新文件的时候,就将该进程的有效ID作为该文件的所有者ID了。APUE里面有时又将文件的所有者ID称为“文件的用户ID”。
一般情况下,进程的有效用户ID就被设成执行该进程的实际用户ID。比如,用户usr01执行了进程process,process的有效用户ID就设成了用户usr01的ID(实际用户ID)。但是有的时候,一个进程可能要去执行其他用户创建的文件。这时,该进程的有效ID和该文件的所有者ID是不同的(记住文件的所有者Id就是最初创建它的进程有效ID哦)。但是如果文件设置了“设置用户ID位”或者“设置组ID位”,那么该进程在执行该文件的时候,就会将进程的有效ID临时更改为文件的所有者ID。
设置用户ID:设置用户ID是由exec函数复制有效用户ID得来的。所以说设置用户ID是进程有效ID的副本。为什么要保留进程有效ID的副本呢?刚才讲到文件有设置用户ID位时,内核会将执行进程的有效ID临时更改为文件的所有者ID。执行完该文件后总要恢复成原来的有效用户ID吧?所以事先保留个副本啦!
关于对应的组ID,基本类似了,不再赘述。
——————————————————————————————————————————————————————————————————
解释二:看UNIX相关的书时经常能遇到这几个概念,但一直没有好好去理清这几个概念,以致对这几个概念一直一知半解。今天好好区分了一下这几个概念并总结如下。说白了这几个UID引出都是为了系统的权限管理。
下面分别用RUID, EUID,SUID来表示实际用户ID,有效用户ID,设置用户ID。另外用户ID是个整型数,为了说明方便真接使用了用户名来代表不同的UID。先解释一下这几个ID的作用:
RUI, 用于在系统中标识一个用户是谁,当用户使用用户名和密码成功登录后一个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。