[UX]unix process-id
来源：互联网 发布：奢侈品软件 编辑：程序博客网 时间：2024/04/29 19:43
引用：Marshall Kirk McKusick, George V. Neville-Neil 的《The Design and Implementation of the FreeBSD Operating System》一书中对这个问题的论述。。。
3.7 User, Group, and Other Identifiers
每个FreeBSD进程的状态里都有一个UID和一组GID。一个进程的文件系统访问特权就是由它的UID和GIDs来定义的。通常，这些标识符都是新进程创建的时候从父进程那儿自动继承过来的。只有超级用户才能修改一个进程的真实UID或真实GID。这个方案在各种特权之间进行了严格的区分，确保除了超级用户之外的其它任何用户都无法获得特权。
每个文件都有三组许可bit，分别用于所有者、组以及其它用户的读、写或执行许可。这些许可bit将按如下顺序进行检查：
1、如果文件的UID和进程的UID相同，则仅应用所有者的许可，不再检查组和其它用户的许可。
2、如果UID不匹配，但文件的GID和进程的众多GID之一匹配，则仅引用组的许可，不再检查所有者和其它用户的许可。
3、仅当进程UID和GID与文件的UID和GID都不匹配时，才会去检查其它用户的许可。如果这些许可不允许所请求的操作，该操作就会失败。
一个进程的UID和GIDs是从它的父进程那儿继承来的。当一个用户登录的时候，login程序会在执行exec系统调用运行用户的登录shell之前设置好UID和GIDs，因此，后续的所有进程都会继承到恰当的标识符。
我们经常会想赋予一个用户有限的额外特权。......为了解决这个问题，内核允许程序在运行过程中创建被赋予特权的程序。以不同的UID运行的程序被称为setuid程序，以一个额外的组特权运行的程序被称为setgid程序。当运行一个setuid程序的时候，进程的许可将被扩展以包括与程序相关联的UID的许可。该程序的UID就被称为进程的有效UID，而进程最初的UID则被称为真实UID。同样，执行一个setgid程序会把进程的许可扩展为程序的GID的许可，相应的也有有效GID和真实GID的定义。
系统可以通过setuid和setgid程序来提供对文件或服务的受控访问。当然，这样的程序必须仔细编写，以保证它们只具有一些有限的功能。
UID和GIDs是作为每个进程的状态的一部分来维护的。由于历史原因，GIDs被实现成了一个显著的GID（即有效GID）和一个GIDs的辅助数组，不过在逻辑上则被看作是一组GIDs。在FreeBSD中，那个显著的GID就是GIDs数组中的第一个条目。辅助数组的大小是固定的（FreeBSD中是16），不过可以通过重新编译内核来修改这个数值。
FreeBSD是通过把运行setgid程序的进程的辅组数组中的第0个元素设置成文件的属组来实现setgid功能的。之后就可以像普通进程那样对许可进行检查了。由于存在额外的组，setgid程序就能够比一个运行没有特殊权限的程序的用户进程访问更多的文件。为了避免在运行一个setgid程序的时候丢失与第0个数组元素中的组相关联的特权，login程序会在初始化用户的辅组数组的时候将第0个数组元素复制到第一个数组元素中。因此，当运行的setgid程序修改第0个元素的时候，用户不会丢失任何特权，因为曾经保存在第0个数组元素中的组仍然可以从第一个数组元素中得到。
setuid功能是通过把进程的有效UID从用户的数值修改为被运行的程序的数值来实现的。和setgid一样，保护机制此时将毫不变样地允许访问，同时也不会意识到程序正在运行setuid。由于一个进程在同一时刻只能有一个UID，在运行setuid的时候就可能会丢失某些特权。在加载新的有效UID的时候，之前的真实UID将会继续作为真实UID。不过真实UID是不会用于任何确认检查的。
一个setuid进程在运行过程中可能会想临时取消它的特殊权限。比如，它可能只在运行开始和结束的时候需要访问某个受限文件的特殊权限。在其余的运行时间中，它应当只具有真实用户的权限。在BSD的早期版本中，特权的回收是通过对真实的和有效的UID进行切换来完成的。由于只有有效UID被用于访问控制，这个方法既提供了所需的语义，又提供了一个隐藏特殊权限的地方。这个方法的缺点是很容易就混淆了真实的和有效的UID。
在FreeBSD中，使用了一个额外的标识符，即saved UID来记录setuid程序的身份。当一个程序被exec之后，它的有效UID会被拷贝到saved UID中。下表中的第1行表示了一个没有特权的程序，它的真实、有效以及saved UID都是真实用户的数值。第2行正在运行中的setuid程序，它的有效UID被设置成了具有相应特权的UID，而这个特权UID也会被拷贝到saved UID中。
Actions affecting the real, effective, and saved UIDs.
_________________________________________________________________
Action Real Effective Saved
1.exec-normal R R R
2.exec-setuid R S S
3.seteuid(R) R R S
4.seteuid(S) R S S
5.seteuid(R) R R S
6.exec-normal R R R
Key:R-real user identifier; S-special-privilege user identifier
_________________________________________________________________
seteuid系统调用只会修改有效UID，而不会影响真实的或saved UID。seteuid系统调用被允许将有效UID修改为真实的或saved UID的数值。表中的第3行和第4行表示了一个setuid程序在一直保持正确的真实UID的同时是如何放弃和重新取回它的特殊权限的。第5行和第6行表示了一个setuid程序可以运行一个子进程而不赋予它特殊权限。首先，它会把它的有效UID设置成真实UID。然后，当exec那个子进程的时候，有效UID就会被拷贝到saved UID中，从此就会失去对特权UID的所有访问。
与此类似，也有一个saved GID机制，允许进程在真实GID和最初的有效GID之间进行切换。
引用：IEEE Std 1003.1™, 2004 Edition
Standard for Information Technology —
Portable Operating System Interface (POSIX)
System Interfaces 中对setuid()的论述。。。
NAME
setuid—set user ID
SYNOPSIS
#include
int setuid(uid_t uid);
DESCRIPTION
If the process has appropriate privileges, setuid( ) shall set the real user ID,
effective user ID, and the saved set-user-ID of the calling process to uid.
If the process does not have appropriate privileges, but uid is equal to the real user
ID or the saved set-user-ID, setuid( ) shall set the effective user ID to uid; the real
user ID and saved set-user-ID shall remain unchanged.
The setuid( ) function shall not affect the supplementary group list in any way.
RETURN VALUE
Upon successful completion, 0 shall be returned. Otherwise, ?1 shall be returned and
errno set to indicate the error.
ERRORS
The setuid( ) function shall fail, return ?1, and set errno to the corresponding value
if one or more of the following are true:
[EINVAL] The value of the uid argument is invalid and not supported by the
implementation.
[EPERM] The process does not have appropriate privileges and uid does not match the
real user ID or the saved set-user-ID.
EXAMPLES
None.
APPLICATION USAGE
None.
RATIONALE
The various behaviors of the setuid( ) and setgid( ) functions when called by
non-privileged processes reflect the behavior of different historical implementations.
For portability, it is recommended that new non-privileged applications use the
seteuid( ) and setegid( ) functions instead.
The saved set-user-ID capability allows a program to regain the effective user ID
established at the last exec call. Similarly, the saved set-group-ID capability allows
a program to regain the effective group ID established at the last exec call.
These capabilities are derived from System V. Without them, a program might have to run
as superuser in order to perform the same functions, because superuser can write on the
user’s files. This is a problem because such a program can write on any user’s files,
and so must be carefully written to emulate the permissions of the calling process
properly. In System V, these capabilities have traditionally been implemented only via
the setuid( ) and setgid( ) functions for non-privileged processes. The fact that the
behavior of those functions was different for privileged processes made them difficult
to use. The POSIX.1-1990 standard defined the setuid( ) function to behave differently
for privileged and unprivileged users. When the caller had the appropriate privilege,
the function set the calling process’ real user ID, effective user ID, and saved
set-user ID on implementations that supported it. When the caller did not have the
appropriate privilege, the function set only the effective user ID, subject to
permission checks. The former use is generally needed for utilities like login and su,
which are not conforming applications and thus outside the scope of IEEE Std
1003.1-2001. These utilities wish to change the user ID irrevocably to a new value,
generally that of an unprivileged user. The latter use is needed for conforming
applications that are installed with the set-user-ID bit and need to perform operations
using the real user ID.
IEEE Std 1003.1-2001 augments the latter functionality with a mandatory feature named
_POSIX_SAVED_IDS. This feature permits a set-user-ID application to switch its
effective user ID back and forth between the values of its exec-time real user ID and
effective user ID. Unfortunately, the POSIX.1-1990 standard did not permit a conforming
application using this feature to work properly when it happened to be executed with
the (implementation-defined) appropriate privilege. Furthermore, the application did
not even have a means to tell whether it had this privilege. Since the saved
set-user-ID feature is quite desirable for applications, as evidenced by the fact that
NIST required it in FIPS 151-2, it has been mandated by IEEE Std 1003.1-2001. However,
there are implementors who have been reluctant to support it given the limitation
described above.
The 4.3BSD system handles the problem by supporting separate functions: setuid( )
(which always sets both the real and effective user IDs, like setuid( ) in IEEE Std
1003.1-2001 for privileged users), and seteuid( ) (which always sets just the effective
user ID, like setuid( ) in IEEE Std 1003.1-2001 for non-privileged users). This
separation of functionality into distinct functions seems desirable. 4.3BSD does not
support the saved set-user-ID feature. It supports similar functionality of switching
the effective user ID back and forth via setreuid( ), which permits reversing the real
and effective user IDs. This model seems less desirable than the saved set-user-ID
because the real user ID changes as a side effect. The current 4.4BSD includes saved
effective IDs and uses them for seteuid( ) and setegid( ) as described above. The
setreuid( ) and setregid( ) functions will be deprecated or removed.
The solution here is:
. Require that all implementations support the functionality of the saved
set-user-ID, which is set by the exec functions and by privileged calls to
setuid( ).
. Add the seteuid( ) and setegid( ) functions as portable alternatives to setuid( )
and setgid( ) for non-privileged and privileged processes.
Historical systems have provided two mechanisms for a set-user-ID process to change its
effective user ID to be the same as its real user ID in such a way that it could return
to the original effective user ID: the use of the setuid( ) function in the presence of
a saved set-user-ID, or the use of the BSD setreuid( ) function, which was able to swap
the real and effective user IDs. The changes included in IEEE Std 1003.1-2001 provide a
new mechanism using seteuid( ) in conjunction with a saved set-user-ID. Thus, all
implementations with the new seteuid( ) mechanism will have a saved set-user-ID for
each process, and most of the behavior controlled by _POSIX_SAVED_IDS has been changed
to agree with the case where the option was defined. The kill ( ) function is an
exception. Implementors of the new seteuid( ) mechanism will generally be required to
maintain compatibility with the older mechanisms previously supported by their systems.
However, compatibility with this use of setreuid( ) and with the _POSIX_SAVED_IDS
behavior of kill ( ) is unfortunately complicated. If an implementation with a saved
set-user-ID allows a process to use setreuid( ) to swap its real and effective user
IDs, but were to leave the saved set-user-ID unmodified, the process would then have an
effective user ID equal to the original real user ID, and both real and saved
set-user-ID would be equal to the original effective user ID. In that state, the real
user would be unable to kill the process, even though the effective user ID of the
process matches that of the real user, if the kill ( ) behavior of _POSIX_SAVED_IDS
was used. This is obviously not acceptable. The alternative choice, which is used in
at least one implementation, is to change the saved set-user-ID to the effective user
ID during most calls to setreuid( ). The standard developers considered that
alternative to be less correct than the retention of the old behavior of kill ( ) in
such systems. Current conforming applications shall accommodate either behavior from
kill ( ), and there appears to be no strong reason for kill( ) to check the saved
set-user-ID rather than the effective user ID.
FUTUREDIRECTIONS
None.
SEE ALSO
exec, getegid( ), geteuid( ), getgid( ), getuid( ), setegid( ), seteuid( ), setgid( ),
setregid( ), setreuid( ), the Base Definitions volume of IEEE Std 1003.1-2001,
<sys/types.h>, <unistd.h>
CHANGE HISTORY
First released in Issue 1. Derived from Issue 1 of the SVID.
Issue 6
In the SYNOPSIS, the optional include of the header is removed.
The following new requirements on POSIX implementations derive from alignment with the
Single UNIX Specification:
. The requirement to include has been removed. Although
was required for conforming implementations of previous POSIX specifications, it
was not required for UNIX applications.
. The functionality associated with _POSIX_SAVED_IDS is now mandatory. This is a FIPS
requirement.
The following changes were made to align with the IEEE P1003.1a draft standard:
. The effects of setuid( ) in processes without appropriate privileges are changed.
. A requirement that the supplementary group list is not affected is added.
flw 回复于：2006-08-31 13:56:16
一个进程的 real user ID 是指运行此进程的用户角色的 ID。
一个进程的 effective user ID 是指此进程目前实际有效的用户 ID（也就是权限的大小），effective user ID 主要用来校验权限时使用，比如打开文件、创建文件、修改文件、kill 别的进程，等等。
如果一个进程是以 root 身份来运行的，那么上面这两个 ID 可以用 setuid/seteuid 随便修改，想怎么改就怎么改，改来改去都可以。
但是如果一个进程是以普通用户身份来运行的，那么上面这两个 ID 一般来说是相同的，并且也不能随便修改。只有一种情况例外：此进程的可执行文件的权限标记中，设置了“设置用户 ID”位！
在命令行中，设置一个可执行文件的“设置用户 ID”位的最简单的方法，就是用
chmod +s /path/to/file
这个命令。
一旦用了这个命令之后，再执行这个文件，
那么生成的进程的 effective user ID 就变成了这个可执行文件的 owner user ID（属主用户 ID），
而 real user ID 仍然是启动这个程序时所用的用户的 ID。
打个比方来说，如果有这样的一个文件：
引用：-rwsr-sr-x 1 susesuse susesuse 7902 2006-08-31 13:22 tuid
注意这个文件已经用 chmod +s 命令设置过“设置用户 ID”位了。
然后我用 flw 这个用户来执行它，那么生成的进程它的 real user ID 就是 flw（因为我是用 flw 运行的），但是 effective user ID 就变成了 susesuse（因为这个可执行文件被设置了“设置用户 ID”位，并且它的 owner user ID 是 susesuse）。
这时，这个进程实际上就有两个用户权限了。只不过目前生效的是 susesuse，因此它目前能够且只能够操作 susesuse 用户的文件，如果现在我又想要操作 flw 用户的文件怎么办？
很简单，只需要 seteuid( getuid() ) 就可以了。执行完这句之后，effective user ID 就变成和 real user ID 一样了，都变成 flw 了。
可是如果过了一会儿我又想要变回来怎么办？因为 effective user ID 和 real user ID 此时都变成了 flw 了，所以操作系统必须得有一个地方保存住原来的“设置用户 ID”（也就是可执行文件的 owner user ID），不然等你再想要 seteuid 的时候，操作系统就不知道你有没有那个权利了。（总不能再去访问一次文件系统吧？那样也太没有效率了）
操作系统为了能够在设置了 seteuid 之后，再次设置回来，所以特地将原来的“设置用户 ID”保存下来了，这个保存下来的设置用户 ID 自然就叫做“保存的设置用户 ID”。
下面看一段我写的例子程序：
flw@Sleeper:~$ whoami
flw
flw@Sleeper:~$ cat tuid.c
# include <stdio.h>
# include <sys/types.h>
# include <pwd.h>
int main( void )
{
struct passwd *pwd;
pwd = getpwuid( geteuid() );
printf( "effective UID: [%s]\n", pwd->pw_name );
system( "touch /tmp/foo.txt; ls -l /tmp/foo.txt; rm -rf /tmp/foo.txt" );
printf( "\nset EUID to `flw'..\n" );
pwd = getpwnam( "flw" );
seteuid(pwd->pw_uid);
pwd = getpwuid( geteuid() );
printf( "effective UID: [%s]\n", pwd->pw_name );
system( "touch /tmp/foo.txt; ls -l /tmp/foo.txt; rm -rf /tmp/foo.txt" );
printf( "\nset EUID to `root'..\n" );
seteuid(0);
pwd = getpwuid( geteuid() );
printf( "effective UID: [%s]\n", pwd->pw_name );
system( "touch /tmp/foo.txt; ls -l /tmp/foo.txt; rm -rf /tmp/foo.txt" );
return 0;
}
flw@Sleeper:~$ su root -c "cc -o tuid tuid.c; chmod +s tuid; ls -al tuid"
Password:
-rwsr-sr-x 1 root root 7902 2006-08-31 13:55 tuid
flw@Sleeper:~$ ./tuid
effective UID: [root]
-rw-r--r-- 1 root root 0 2006-08-31 13:55 /tmp/foo.txt
set EUID to `flw'..
effective UID: [flw]
-rw-r--r-- 1 flw root 0 2006-08-31 13:55 /tmp/foo.txt
set EUID to `root'..
effective UID: [root]
-rw-r--r-- 1 root root 0 2006-08-31 13:55 /tmp/foo.txt
flw@Sleeper:~$
3.7 User, Group, and Other Identifiers
每个FreeBSD进程的状态里都有一个UID和一组GID。一个进程的文件系统访问特权就是由它的UID和GIDs来定义的。通常，这些标识符都是新进程创建的时候从父进程那儿自动继承过来的。只有超级用户才能修改一个进程的真实UID或真实GID。这个方案在各种特权之间进行了严格的区分，确保除了超级用户之外的其它任何用户都无法获得特权。
每个文件都有三组许可bit，分别用于所有者、组以及其它用户的读、写或执行许可。这些许可bit将按如下顺序进行检查：
1、如果文件的UID和进程的UID相同，则仅应用所有者的许可，不再检查组和其它用户的许可。
2、如果UID不匹配，但文件的GID和进程的众多GID之一匹配，则仅引用组的许可，不再检查所有者和其它用户的许可。
3、仅当进程UID和GID与文件的UID和GID都不匹配时，才会去检查其它用户的许可。如果这些许可不允许所请求的操作，该操作就会失败。
一个进程的UID和GIDs是从它的父进程那儿继承来的。当一个用户登录的时候，login程序会在执行exec系统调用运行用户的登录shell之前设置好UID和GIDs，因此，后续的所有进程都会继承到恰当的标识符。
我们经常会想赋予一个用户有限的额外特权。......为了解决这个问题，内核允许程序在运行过程中创建被赋予特权的程序。以不同的UID运行的程序被称为setuid程序，以一个额外的组特权运行的程序被称为setgid程序。当运行一个setuid程序的时候，进程的许可将被扩展以包括与程序相关联的UID的许可。该程序的UID就被称为进程的有效UID，而进程最初的UID则被称为真实UID。同样，执行一个setgid程序会把进程的许可扩展为程序的GID的许可，相应的也有有效GID和真实GID的定义。
系统可以通过setuid和setgid程序来提供对文件或服务的受控访问。当然，这样的程序必须仔细编写，以保证它们只具有一些有限的功能。
UID和GIDs是作为每个进程的状态的一部分来维护的。由于历史原因，GIDs被实现成了一个显著的GID（即有效GID）和一个GIDs的辅助数组，不过在逻辑上则被看作是一组GIDs。在FreeBSD中，那个显著的GID就是GIDs数组中的第一个条目。辅助数组的大小是固定的（FreeBSD中是16），不过可以通过重新编译内核来修改这个数值。
FreeBSD是通过把运行setgid程序的进程的辅组数组中的第0个元素设置成文件的属组来实现setgid功能的。之后就可以像普通进程那样对许可进行检查了。由于存在额外的组，setgid程序就能够比一个运行没有特殊权限的程序的用户进程访问更多的文件。为了避免在运行一个setgid程序的时候丢失与第0个数组元素中的组相关联的特权，login程序会在初始化用户的辅组数组的时候将第0个数组元素复制到第一个数组元素中。因此，当运行的setgid程序修改第0个元素的时候，用户不会丢失任何特权，因为曾经保存在第0个数组元素中的组仍然可以从第一个数组元素中得到。
setuid功能是通过把进程的有效UID从用户的数值修改为被运行的程序的数值来实现的。和setgid一样，保护机制此时将毫不变样地允许访问，同时也不会意识到程序正在运行setuid。由于一个进程在同一时刻只能有一个UID，在运行setuid的时候就可能会丢失某些特权。在加载新的有效UID的时候，之前的真实UID将会继续作为真实UID。不过真实UID是不会用于任何确认检查的。
一个setuid进程在运行过程中可能会想临时取消它的特殊权限。比如，它可能只在运行开始和结束的时候需要访问某个受限文件的特殊权限。在其余的运行时间中，它应当只具有真实用户的权限。在BSD的早期版本中，特权的回收是通过对真实的和有效的UID进行切换来完成的。由于只有有效UID被用于访问控制，这个方法既提供了所需的语义，又提供了一个隐藏特殊权限的地方。这个方法的缺点是很容易就混淆了真实的和有效的UID。
在FreeBSD中，使用了一个额外的标识符，即saved UID来记录setuid程序的身份。当一个程序被exec之后，它的有效UID会被拷贝到saved UID中。下表中的第1行表示了一个没有特权的程序，它的真实、有效以及saved UID都是真实用户的数值。第2行正在运行中的setuid程序，它的有效UID被设置成了具有相应特权的UID，而这个特权UID也会被拷贝到saved UID中。
Actions affecting the real, effective, and saved UIDs.
_________________________________________________________________
Action Real Effective Saved
1.exec-normal R R R
2.exec-setuid R S S
3.seteuid(R) R R S
4.seteuid(S) R S S
5.seteuid(R) R R S
6.exec-normal R R R
Key:R-real user identifier; S-special-privilege user identifier
_________________________________________________________________
seteuid系统调用只会修改有效UID，而不会影响真实的或saved UID。seteuid系统调用被允许将有效UID修改为真实的或saved UID的数值。表中的第3行和第4行表示了一个setuid程序在一直保持正确的真实UID的同时是如何放弃和重新取回它的特殊权限的。第5行和第6行表示了一个setuid程序可以运行一个子进程而不赋予它特殊权限。首先，它会把它的有效UID设置成真实UID。然后，当exec那个子进程的时候，有效UID就会被拷贝到saved UID中，从此就会失去对特权UID的所有访问。
与此类似，也有一个saved GID机制，允许进程在真实GID和最初的有效GID之间进行切换。
引用：IEEE Std 1003.1™, 2004 Edition
Standard for Information Technology —
Portable Operating System Interface (POSIX)
System Interfaces 中对setuid()的论述。。。
NAME
setuid—set user ID
SYNOPSIS
#include
int setuid(uid_t uid);
DESCRIPTION
If the process has appropriate privileges, setuid( ) shall set the real user ID,
effective user ID, and the saved set-user-ID of the calling process to uid.
If the process does not have appropriate privileges, but uid is equal to the real user
ID or the saved set-user-ID, setuid( ) shall set the effective user ID to uid; the real
user ID and saved set-user-ID shall remain unchanged.
The setuid( ) function shall not affect the supplementary group list in any way.
RETURN VALUE
Upon successful completion, 0 shall be returned. Otherwise, ?1 shall be returned and
errno set to indicate the error.
ERRORS
The setuid( ) function shall fail, return ?1, and set errno to the corresponding value
if one or more of the following are true:
[EINVAL] The value of the uid argument is invalid and not supported by the
implementation.
[EPERM] The process does not have appropriate privileges and uid does not match the
real user ID or the saved set-user-ID.
EXAMPLES
None.
APPLICATION USAGE
None.
RATIONALE
The various behaviors of the setuid( ) and setgid( ) functions when called by
non-privileged processes reflect the behavior of different historical implementations.
For portability, it is recommended that new non-privileged applications use the
seteuid( ) and setegid( ) functions instead.
The saved set-user-ID capability allows a program to regain the effective user ID
established at the last exec call. Similarly, the saved set-group-ID capability allows
a program to regain the effective group ID established at the last exec call.
These capabilities are derived from System V. Without them, a program might have to run
as superuser in order to perform the same functions, because superuser can write on the
user’s files. This is a problem because such a program can write on any user’s files,
and so must be carefully written to emulate the permissions of the calling process
properly. In System V, these capabilities have traditionally been implemented only via
the setuid( ) and setgid( ) functions for non-privileged processes. The fact that the
behavior of those functions was different for privileged processes made them difficult
to use. The POSIX.1-1990 standard defined the setuid( ) function to behave differently
for privileged and unprivileged users. When the caller had the appropriate privilege,
the function set the calling process’ real user ID, effective user ID, and saved
set-user ID on implementations that supported it. When the caller did not have the
appropriate privilege, the function set only the effective user ID, subject to
permission checks. The former use is generally needed for utilities like login and su,
which are not conforming applications and thus outside the scope of IEEE Std
1003.1-2001. These utilities wish to change the user ID irrevocably to a new value,
generally that of an unprivileged user. The latter use is needed for conforming
applications that are installed with the set-user-ID bit and need to perform operations
using the real user ID.
IEEE Std 1003.1-2001 augments the latter functionality with a mandatory feature named
_POSIX_SAVED_IDS. This feature permits a set-user-ID application to switch its
effective user ID back and forth between the values of its exec-time real user ID and
effective user ID. Unfortunately, the POSIX.1-1990 standard did not permit a conforming
application using this feature to work properly when it happened to be executed with
the (implementation-defined) appropriate privilege. Furthermore, the application did
not even have a means to tell whether it had this privilege. Since the saved
set-user-ID feature is quite desirable for applications, as evidenced by the fact that
NIST required it in FIPS 151-2, it has been mandated by IEEE Std 1003.1-2001. However,
there are implementors who have been reluctant to support it given the limitation
described above.
The 4.3BSD system handles the problem by supporting separate functions: setuid( )
(which always sets both the real and effective user IDs, like setuid( ) in IEEE Std
1003.1-2001 for privileged users), and seteuid( ) (which always sets just the effective
user ID, like setuid( ) in IEEE Std 1003.1-2001 for non-privileged users). This
separation of functionality into distinct functions seems desirable. 4.3BSD does not
support the saved set-user-ID feature. It supports similar functionality of switching
the effective user ID back and forth via setreuid( ), which permits reversing the real
and effective user IDs. This model seems less desirable than the saved set-user-ID
because the real user ID changes as a side effect. The current 4.4BSD includes saved
effective IDs and uses them for seteuid( ) and setegid( ) as described above. The
setreuid( ) and setregid( ) functions will be deprecated or removed.
The solution here is:
. Require that all implementations support the functionality of the saved
set-user-ID, which is set by the exec functions and by privileged calls to
setuid( ).
. Add the seteuid( ) and setegid( ) functions as portable alternatives to setuid( )
and setgid( ) for non-privileged and privileged processes.
Historical systems have provided two mechanisms for a set-user-ID process to change its
effective user ID to be the same as its real user ID in such a way that it could return
to the original effective user ID: the use of the setuid( ) function in the presence of
a saved set-user-ID, or the use of the BSD setreuid( ) function, which was able to swap
the real and effective user IDs. The changes included in IEEE Std 1003.1-2001 provide a
new mechanism using seteuid( ) in conjunction with a saved set-user-ID. Thus, all
implementations with the new seteuid( ) mechanism will have a saved set-user-ID for
each process, and most of the behavior controlled by _POSIX_SAVED_IDS has been changed
to agree with the case where the option was defined. The kill ( ) function is an
exception. Implementors of the new seteuid( ) mechanism will generally be required to
maintain compatibility with the older mechanisms previously supported by their systems.
However, compatibility with this use of setreuid( ) and with the _POSIX_SAVED_IDS
behavior of kill ( ) is unfortunately complicated. If an implementation with a saved
set-user-ID allows a process to use setreuid( ) to swap its real and effective user
IDs, but were to leave the saved set-user-ID unmodified, the process would then have an
effective user ID equal to the original real user ID, and both real and saved
set-user-ID would be equal to the original effective user ID. In that state, the real
user would be unable to kill the process, even though the effective user ID of the
process matches that of the real user, if the kill ( ) behavior of _POSIX_SAVED_IDS
was used. This is obviously not acceptable. The alternative choice, which is used in
at least one implementation, is to change the saved set-user-ID to the effective user
ID during most calls to setreuid( ). The standard developers considered that
alternative to be less correct than the retention of the old behavior of kill ( ) in
such systems. Current conforming applications shall accommodate either behavior from
kill ( ), and there appears to be no strong reason for kill( ) to check the saved
set-user-ID rather than the effective user ID.
FUTUREDIRECTIONS
None.
SEE ALSO
exec, getegid( ), geteuid( ), getgid( ), getuid( ), setegid( ), seteuid( ), setgid( ),
setregid( ), setreuid( ), the Base Definitions volume of IEEE Std 1003.1-2001,
<sys/types.h>, <unistd.h>
CHANGE HISTORY
First released in Issue 1. Derived from Issue 1 of the SVID.
Issue 6
In the SYNOPSIS, the optional include of the header is removed.
The following new requirements on POSIX implementations derive from alignment with the
Single UNIX Specification:
. The requirement to include has been removed. Although
was required for conforming implementations of previous POSIX specifications, it
was not required for UNIX applications.
. The functionality associated with _POSIX_SAVED_IDS is now mandatory. This is a FIPS
requirement.
The following changes were made to align with the IEEE P1003.1a draft standard:
. The effects of setuid( ) in processes without appropriate privileges are changed.
. A requirement that the supplementary group list is not affected is added.
flw 回复于：2006-08-31 13:56:16
一个进程的 real user ID 是指运行此进程的用户角色的 ID。
一个进程的 effective user ID 是指此进程目前实际有效的用户 ID（也就是权限的大小），effective user ID 主要用来校验权限时使用，比如打开文件、创建文件、修改文件、kill 别的进程，等等。
如果一个进程是以 root 身份来运行的，那么上面这两个 ID 可以用 setuid/seteuid 随便修改，想怎么改就怎么改，改来改去都可以。
但是如果一个进程是以普通用户身份来运行的，那么上面这两个 ID 一般来说是相同的，并且也不能随便修改。只有一种情况例外：此进程的可执行文件的权限标记中，设置了“设置用户 ID”位！
在命令行中，设置一个可执行文件的“设置用户 ID”位的最简单的方法，就是用
chmod +s /path/to/file
这个命令。
一旦用了这个命令之后，再执行这个文件，
那么生成的进程的 effective user ID 就变成了这个可执行文件的 owner user ID（属主用户 ID），
而 real user ID 仍然是启动这个程序时所用的用户的 ID。
打个比方来说，如果有这样的一个文件：
引用：-rwsr-sr-x 1 susesuse susesuse 7902 2006-08-31 13:22 tuid
注意这个文件已经用 chmod +s 命令设置过“设置用户 ID”位了。
然后我用 flw 这个用户来执行它，那么生成的进程它的 real user ID 就是 flw（因为我是用 flw 运行的），但是 effective user ID 就变成了 susesuse（因为这个可执行文件被设置了“设置用户 ID”位，并且它的 owner user ID 是 susesuse）。
这时，这个进程实际上就有两个用户权限了。只不过目前生效的是 susesuse，因此它目前能够且只能够操作 susesuse 用户的文件，如果现在我又想要操作 flw 用户的文件怎么办？
很简单，只需要 seteuid( getuid() ) 就可以了。执行完这句之后，effective user ID 就变成和 real user ID 一样了，都变成 flw 了。
可是如果过了一会儿我又想要变回来怎么办？因为 effective user ID 和 real user ID 此时都变成了 flw 了，所以操作系统必须得有一个地方保存住原来的“设置用户 ID”（也就是可执行文件的 owner user ID），不然等你再想要 seteuid 的时候，操作系统就不知道你有没有那个权利了。（总不能再去访问一次文件系统吧？那样也太没有效率了）
操作系统为了能够在设置了 seteuid 之后，再次设置回来，所以特地将原来的“设置用户 ID”保存下来了，这个保存下来的设置用户 ID 自然就叫做“保存的设置用户 ID”。
下面看一段我写的例子程序：
flw@Sleeper:~$ whoami
flw
flw@Sleeper:~$ cat tuid.c
# include <stdio.h>
# include <sys/types.h>
# include <pwd.h>
int main( void )
{
struct passwd *pwd;
pwd = getpwuid( geteuid() );
printf( "effective UID: [%s]\n", pwd->pw_name );
system( "touch /tmp/foo.txt; ls -l /tmp/foo.txt; rm -rf /tmp/foo.txt" );
printf( "\nset EUID to `flw'..\n" );
pwd = getpwnam( "flw" );
seteuid(pwd->pw_uid);
pwd = getpwuid( geteuid() );
printf( "effective UID: [%s]\n", pwd->pw_name );
system( "touch /tmp/foo.txt; ls -l /tmp/foo.txt; rm -rf /tmp/foo.txt" );
printf( "\nset EUID to `root'..\n" );
seteuid(0);
pwd = getpwuid( geteuid() );
printf( "effective UID: [%s]\n", pwd->pw_name );
system( "touch /tmp/foo.txt; ls -l /tmp/foo.txt; rm -rf /tmp/foo.txt" );
return 0;
}
flw@Sleeper:~$ su root -c "cc -o tuid tuid.c; chmod +s tuid; ls -al tuid"
Password:
-rwsr-sr-x 1 root root 7902 2006-08-31 13:55 tuid
flw@Sleeper:~$ ./tuid
effective UID: [root]
-rw-r--r-- 1 root root 0 2006-08-31 13:55 /tmp/foo.txt
set EUID to `flw'..
effective UID: [flw]
-rw-r--r-- 1 flw root 0 2006-08-31 13:55 /tmp/foo.txt
set EUID to `root'..
effective UID: [root]
-rw-r--r-- 1 root root 0 2006-08-31 13:55 /tmp/foo.txt
flw@Sleeper:~$
0 0
- [UX]unix process-id
- [UX]unix log view
- unix daemon process
- unix process control
- Unix process(2)
- Obtain current process ID
- JNI - Process ID
- hp-ux(unix)的日志文件
- get android process id and thread id
- Unix process(3) vs. thread
- Process ID and special processes
- Get Process ID by Name
- Awk print the process ID
- UX
- UX
- AIX/Unix/Linux/HP-UX 系统中文字符集
- AIX/Unix/Linux/HP-UX 系统中文字符集
- AIX/Unix/Linux/HP-UX 系统中文字符编码设置
- http中的Content-Type
- Xcode下Build Settings选项列表问题
- JSP中table中数据自动换行的问题
- AXIS2发布WebService的方法
- 无脑码农Cocos2d教程系列
- [UX]unix process-id
- 多线程的那点儿事（之嵌套锁）
- Android ColorStateList使用方法
- JAVA 插入排序 稳定
- hadoop监控系统
- 【Java编程】Java学习笔记<二>
- WebDriver 与Autoit结合完成文件上传
- 多线程的那点儿事（之生产者-消费者）
- Android 传感器的使用
