Usid与Guid的一些理解

这篇文章总结好久了，只是按照这个思路去做实验，一直得不到验证，不知道问题出在哪，就先发出来，免得文档丢了）——

参考文档:

http://blog.csdn.net/jxth152913/article/details/5738188

昨天晚上在csdn论坛上看到有人发帖，问系统为什么要整出uid，gid，euid这么多东西，直接一个用户一个uid，只用这个uid不就行了，那linux引入这么多id的初衷是什么？

我看到这个帖子的第一反应就是suid，因为原本在搞selinux的时候接触过这一概念，但是当我给人回帖的时候，才发现自己理解的并不透彻，于是又查了些资料，现在感觉理解有些清晰了，在这整理出来。

引入suid的好处

这个概念主要仿照参考文档中的解释，我感觉这个解释是十分容易让人深刻理解的。比如我是个数据库管理员，管理者几个大型数据库。对这些数据库的备份工作需要管理员权限。而我也比较忙，没办法总是亲自完成这个备份工作，然而如果把管理员的账号密码告诉别人，又增加了数据库的安全隐患。这时候就可以使用usid这个机制来达到两全。这个时候，我就可以编写几个脚本文件，属主是我，但是给我指定的可以完成备份的人赋予执行的权限，这里要区分这个概念，这些指定的人虽然有执行脚本的权限，但却不一定能够完成备份工作，因为这些脚本要完成备份需要调用其他文件，但是这些指定的人却没有这些脚本要调用的文件的读写或执行权限。这种情况下，脚本还是会执行失败。

怎么办呢，引入suid。我作为管理员，我可以把这些属于我的脚本赋予suid权限，这样，当我指定的人去执行脚本的时候，系统内核判断这个程序的有效uid就不是当前执行此程序的uid，而是具有了属主即系统管理员的uid。于是，程序就可以行使数据库管理员的权利，读取需要读取的文件，完成备份操作。

当脚本完成之后，内核的有效uid又变回了当前用户的uid。这样就可以不分配脚本读取文件的永久权限给那些无关的用户，同时又可以使这些用户能够完成指定脚本的执行工作。

上文有一个概念，就是

有效uid，即euid。

Euid是个动态的概念，它是可变的。

系统内核主要是根据euid来确定进程对资源的访问权限而非执行这个程序的用户的uid。一个进程如果没有SUID位，则euid=uid分别是运行这个程序的用户的uid。例如current用户的uid为204，owner用户的uid 200，current运行owner用户的my.exe（假定current也有x权限）程序形成的进程的euid=uid=204。如果这个程序设置了SUID位，那么此时的euid=owner用户的uid=200。

再说下suid的设置。

设置suid的文件，主要是权限信息中的执行那一位由“x”变成了“s”

形如 -rws rwx ---

配置方法可以使用chmod命令，如

Chomod  u+s  my.file

也可以使用数字，使用数字的时候需要再权限数字前加个“4”，如

Chmod   4770   my.file

就是把my.file文件的权限设置成rwsrwx---。

就这些了。Sgid跟suid是一类概念，类比可知。