real user id, effective user id, saved user id

转自： https://blog.csdn.net/fmeng23/article/details/23115989#

When executing shell scripts that have the setuid bit (e.g., perms of rwsr-xr-x), the scripts run as the user that executes them, not as the user that owns them. This is contrary to how setuid is handled for binaries (e.g., /usr/bin/passwd), which run as the user that owns them, regardless of which user executes them.

Check this page: https://access.redhat.com/site/solutions/124693

This is a security measure taken by operating system. You should use your script with sudo instead.

If you really need to use setuid o your script you can create a binary that will do the work. Create a new file “program.c” and copy the following code:

#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <unistd.h>

int main()
{
setuid(0);
system("./program.sh");
return 0;
}
Compile and execute the code using the following commands:

$ gcc program.c -o program
$ sudo chown root.root program
$ sudo chmod 4755 program
$ ./program
This way it will work.The setuid works for compiled file, and this file can execute others files as root.

---

---

---

These parameters(real user id, effective user id, saved user id) belong to a process. Your given example describes not a process but a file. You’d only get a process if you ran that file as a program.

The initial effective UID (as well as the saved UID) can be guessed here: since the file has the ‘setuid’ flag set, and is owned by the user ‘anna’, running it will create a process with the effective UID of the ‘anna’ user.

Meanwhile, the initial real UID is always based on the user who ran the program and created the process. You can use id to see yours. In fact, you could copy id to a temporary place, change its owner, set the ‘setuid’ bit, and see what values it prints out.

However, a process may swap its real and effective UIDs, or if owned by root change them to anything. To know the UIDs of a specific process you should examine the process – on Linux, this can be done by reading /proc//status and includes all the UIDs, GIDs, supplementary groups, and so on.

---

---

process里面有三个user id,刚开始真是一个令人感觉头痛的地方。因为很容易混淆。但是慢慢的，抓住了一些关键的原因和特点，就可以比较容易理解了。process的三个ID分别是real user id, effective user id, saved set-user-id。对于group有相同的情况，我们可以照下文类推。

首先要注意的是，real user id是真正process执行起来的用户user id，这个是比较清楚的，这个进程是哪个用户调用的，或者是哪个父进程发起的，这个都是很明显的。通常这个是不更改的，也不需要更改。

然后要注意的是，当判定一个进程是否对于某个文件有权限的时候，要验证的ID是effective user id，而非real user id。那effective user id是如何被设置进来的呢？
Linux通常都不建议用户使用root权限去进行一般的处理，但是普通用户在做很多很多services相关的操作的时候，可能需要一个特殊的权限。为 了满足这样的要求，许多services相关的executable有一个标志，这就是set-user-id bit。当这个ser-user-id bit=ON的时候，这个executable被用exec启动之后的进程的effective user id就是这个executable的owner id，而并非parent process real user id。如果set-user-id bit=OFF的时候，这个被exec起来的进程的effective user id应该是等于进程的user id的。

那这样我们就清楚了，设定一个effective user id的意义在于，它可能和real user id不同。那么为什么要设置一个saved set-user-id呢？它的意义是，它相当于是一个buffer， 在exec启动进程之后，它会从effective user id位拷贝信息到自己。对于非root用户，可以在未来使用setuid()来将effective user id设置成为real user id和saved set-user-id中的任何一个。但是非root用户是不允许用setuid()把effective user id设置成为任何第三个user id。

对于root来说，就没有那么大的意义了。因为root调用setuid()的时候，将会设置所有的这三个user id位。所以可以综合说，这三个位的设置为为了让unprivilege user可以获得两种不同的permission而设置的。

APUE的例子是，普通用户去执行一个tip进程，set-user-id bit=ON，执行起来的时候，进程可以有uucp (executable owner)的权限来写lock文件，也有当前普通用户的权限来写数据文件。在两种文件操作之间，使用setuid()来切换effective user id。但是正是因为setuid()的限制，该进程无法获得更多的第三种用户的权限。

其他东西

saved set-user-id是无法取出来的，是kernel来控制的。注意saved set-user-id是进程中的id，而set-user-id bit则是文件上的权限。我用了比较长的时间才分清楚。

Each UNIX proces has 3 UIDs associated to it. Superuser privilege is UID=0.

Real UID

This is the UID of the user/process that created THIS process. It can be changed only if the running process has EUID=0.

Effective UID

This UID is used to evaluate privileges of the process to perform a particular action. EUID can be change either to RUID, or SUID if EUID!=0. If EUID=0, it can be changed to anything.

Saved UID

If the binary image file, that was launched has a Set-UID bit on, SUID will be the UID of the owner of the file. Otherwise, SUID will be the RUID.

What is the idea behind this?

Normal programs, like “ls”, “cat”, “echo” will be run by a normal user, under that users UID. Special programs that allow user to have controlled access to protected data, can have Set-UID bit to allow the program to be run under privileged UID.

An example of such program is “passwd”. If you list it in full, you will see that it has Set-UID bit and the owner is “root”. When a normal user, say “ananta”, runs “passwd”, passwd starts with:

Real-UID = ananta
Effective-UID = ananta
Saved-UID = root

The the program calls a system call “seteuid( 0 )” and since SUID=0, the call will succede and the UIDs will be:

Real-UID = ananta
Effective-UID = root
Saved-UID = root

After that, “passwd” process will be able to access /etc/passwd and change password for user “ananta”. Note that user “ananta” cannot write to /etc/passwd on it’s own. Note one other thing, setting a Set-UID on a executable file is not enough to make it run as privileged process. The program itself must make a system call.

Unix中常见的几个概念,下面做一个解释.

首先需要明确一点,这几个概念都是和进程相关的.

real user ID表示的是实际上进程的执行者是谁,effective user ID主要用于校验该进程在执行时所获得的文件访问权限,也就是说当进程访问文件时检查权限时实际上检查的该进程的"effective user ID",saved set-user-ID 仅在effective user ID发生改变时保存.

一般情况下,real user ID就是进程的effective user ID,但是当要运行的可执行程序设置了"set-user-ID" 位之后,进程的effective user ID变成该文件的属主用户id,同时该进程的"saved set-user-ID"变成此时进程的"effective user ID",也就是该可执行程序的属主用户ID,该进程在执行一些与文件访问权限相关的操作时系统检查的是进程的effective user ID.

为什么需要一个"saved set-user-ID"?因为当进程没有超级用户权限的时候,进程在设置"effective user ID"时需要将需要设置的ID和该进程的"real user ID"或者"saved set-user-ID"进行比较.

APUE2中进行的解释是:
1)If the process has superuser privileges, the setuid function sets the real user ID, effective user ID, and saved set-user-ID to uid.

2)If the process does not have superuser privileges, but uid equals either the real user ID or the saved set-user-ID, setuid sets only the effective user ID to uid. The real user ID and the saved set-user-ID are not changed.

3)If neither of these two conditions is true, errno is set to EPERM, and 1 is returned
也就是说:
1)当用户具有超级用户权限的时候,setuid 函数设置的id对三者都起效.
2)否则,仅当该id为real user ID 或者saved set-user-ID时,该id对effective user ID起效.
3)否则,setuid函数调用失败.

也就是说,这个saved set-user-ID更多的作用是在进程切换自己的effective user ID起作用.

需要特别提醒的是:并没有任何的API可以获取到进程的saved set-user-ID,它仅仅是系统在调用setuid函数时进行比较而起作用的.
APUE2中关于此事的原话如下:
Note that we can obtain only the current value of the real user ID and the effective user ID with the functions getuid and geteuid from Section 8.2. We can’t obtain the current value of the saved set-user-ID.

举一个例子说明问题,假设这样的一种情况,系统中有两个用户A,B,还有一个由B创建的可执行程序proc,该可执行程序的set-
user-id位已经进行了设置.
当A用户执行程序proc时,

程序的real user ID = A的用户ID,effective user ID = B的用户ID, saved set-user-ID=B的用户ID.

假如在该进程结束了对某些限制只能由用户B访问的文件操作后,程序将effective user ID设置回A,也就是说此时:

程序的real user ID = A的用户ID,effective user ID = A的用户ID, saved set-user-ID=B的用户ID.

这个改动之所以能成功,原因在于上面列举出的情况2):该ID为进程的real user ID.

最后,假设由于种种原因进程需要再次切换effective user ID为B,可是因为不能通过API获取进程的saved set-user-ID(该值为B的用户ID),所以只能通过两种途径获得(可能还有别的途径):

a)在设置effective user ID变回A之前保存effective user ID,它的值为B的用户ID.
b)调用函数getpwnam( “B”),在返回的struct passwd *指针中成员pw_uid存放的就是用户B的ID.
这样,这个调用setuid(B的用户ID)就会成功,原因也在于上面说的情况2):该ID与进程的saved set-user-ID相同.

APUE2中关于这几个值的相关解释在section4.4和section8.11中都有涉及.

总结：