linux 中实际用户ID”、“有效用户ID”和“保存的设置用户ID”三个术语
p2277.6THEUSERIDOFAPROCESS
内核会给每个进程关联两个和进程ID无关的用户ID，一个是真实用户ID，还有一个是有效用户ID或者称为 setuid（setuserID）。真实用户ID用于标识由谁为正在运行的进程负责。有效用户ID用于为新创建的文件分配所有权、检查文件访问许可，还用于通过kill系统调用向其它进程发送信号时的许可检查。内核允许一个进程以调用exec一个setuid程序或者显式执行setuid系统调用的方式改变它的有效用户ID。
所谓setuid程序是指一个设置了许可模式字段中的setuidbit的可执行文件。当一个进程exec一个setuid程序的时候，内核会把进程表以及u区中的有效用户ID设置成该文件所有者的ID。为了区分这两个字段，我们把进程表中的那个字段称作保存用户ID。可以通过一个例子来演示这两个字段的区别。
setuid系统调用的语法是setuid(uid)，其中，uid是新的用户ID，该系统调用的结果取决于有效用户ID的当前值。如果调用进程的有效用户ID是超级用户，内核会把进程表以及u区中的真实和有效用户ID都设置成uid。如果调用进程的有效用户ID不是超级用户，仅当uid等于真实用户ID或保存用户ID时，内核才会把u区中的有效用户ID设置成uid。否则，该系统调用将返回错误。一般来说，一个进程会在fork系统调用期间从父进程那儿继承它的真实和有效用户ID，这些数值即使经过exec系统调用也会保持不变。
存储在u区中的有效用户ID是最近一次setuid系统调用或是exec一个setuid程序的结果；只有它会被用于文件访问许可。进程表中的保存用户ID使得一个进程可以通过执行setuid系统调用把有效用户ID设置成它的值，以此来恢复最初的有效用户ID。
setuid程序的例子：login，mkdir。
引用：UreshVahalia的《UNIXInternals：TheNewFrontiers》一书中对这个问题的论述。。。
p27
2.3.3UserCredentials
UID和GID这样的标识符会影响文件的所有权和访问许可，以及向其它进程发送信号的能力。这些属性统称为凭证。
每个进程都有两对ID——真实的和有效的。当一个用户登录的时候，login程序会把两对ID设置成密码数据库（/etc/passwd文件，或某些如SunMicrosystems的NIS之类的分布式机制）中指定的UID和GID。当一个进程fork的时候，子进程将从父进程那儿继承它的凭证。
有效UID和有效GID印象文件的创建和访问。在创建文件的时候，内核将文件的所有者属性设置成创建进程的有效UID和有效GID。在访问文件的时候，内核使用进程的有效UID和GID来判断它是否能够访问该文件。真实UID和真实GID标识进程的真实所有者，会影响到发送信号的权限。对于一个没有超级用户权限的进程来说，仅当它的真实或有效UID于另一个进程的真实UID匹配时它才能向那个进程发送信号。
有三个系统调用可以改变凭证。如果一个进程调用exec执行一个安装为suid模式的程序，内核将把进程的有效UID修改成文件的所有者。同样，如果该程序安装为sgid模式，内核则会去修改调用进程的有效GID。UNIX提供这个特性是想赋予用户特殊的权限以完成一些特定的任务。
一个用户还可以通过调用setuid或setgid来改变它的凭证。超级用户可以通过这些系统调用改变真实的和有效的UID以及GID。普通用户则只能通过这些调用来把它们的有效UID或GID改回到真实的数值。
SystemV和BSDUNIX在处理凭证方面存在着一些差别。SVR3还维护了一个savedUID和savedGID，分别是在调用 exec之前的有效UID和GID的数值。setuid和setgid系统调用还可以把有效ID恢复为保存的数值。4.3BSD不支持这一特性，它允许一个用户属于一个辅组（supplementalgroup）的集合（使用setgroups系统调用）。用户创建的文件将属于它的主组（primarygroup），而用户则既可以访问属于主组的文件，也可以访问属于辅组的文件。
SVR4整合了上述所有特性。它支持附组，也会在exec的时候维护savedUID和GID。
setuid程序的例子：passwd。
引用：MarshallKirkMcKusick,GeorgeV.Neville-Neil的《TheDesignandImplementationoftheFreeBSDOperatingSystem》一书中对这个问题的论述。。。
3.7User,Group,andOtherIdentifiers
每个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中，使用了一个额外的标识符，即savedUID来记录setuid程序的身份。当一个程序被exec之后，它的有效UID会被拷贝到savedUID中。下表中的第1行表示了一个没有特权的程序，它的真实、有效以及savedUID都是真实用户的数值。第2行正在运行中的 setuid程序，它的有效UID被设置成了具有相应特权的UID，而这个特权UID也会被拷贝到savedUID中。
Actionsaffectingthereal,effective,andsavedUIDs.
_________________________________________________________________
ActionRealEffectiveSaved
1.exec-normalRRR
2.exec-setuidRSS
3.seteuid(R)RRS
4.seteuid(S)RSS
5.seteuid(R)RRS
6.exec-normalRRR
Key:R-realuseridentifier;S-special-privilegeuseridentifier
_________________________________________________________________
seteuid系统调用只会修改有效UID，而不会影响真实的或savedUID。seteuid系统调用被允许将有效UID修改为真实的或 savedUID的数值。表中的第3行和第4行表示了一个setuid程序在一直保持正确的真实UID的同时是如何放弃和重新取回它的特殊权限的。第5 行和第6行表示了一个setuid程序可以运行一个子进程而不赋予它特殊权限。首先，它会把它的有效UID设置成真实UID。然后，当exec那个子进程的时候，有效UID就会被拷贝到savedUID中，从此就会失去对特权UID的所有访问。
与此类似，也有一个savedGID机制，允许进程在真实GID和最初的有效GID之间进行切换。
引用：IEEEStd1003.1™,2004Edition
StandardforInformationTechnology—
PortableOperatingSystemInterface(POSIX)
SystemInterfaces中对setuid()的论述。。。
NAME
setuid—setuserID
SYNOPSIS
#include
intsetuid(uid_tuid);
DESCRIPTION
Iftheprocesshasappropriateprivileges,setuid()shallsettherealuserID,
effectiveuserID,andthesavedset-user-IDofthecallingprocesstouid.
Iftheprocessdoesnothaveappropriateprivileges,butuidisequaltotherealuser
IDorthesavedset-user-ID,setuid()shallsettheeffectiveuserIDtouid;thereal
userIDandsavedset-user-IDshallremainunchanged.
Thesetuid()functionshallnotaffectthesupplementarygrouplistinanyway.
RETURNVALUE
Uponsuccessfulcompletion,0shallbereturned.Otherwise,?1shallbereturnedand
errnosettoindicatetheerror.
ERRORS
Thesetuid()functionshallfail,return?1,andseterrnotothecorrespondingvalue
ifoneormoreofthefollowingaretrue:
Thevalueoftheuidargumentisinvalidandnotsupportedbythe
implementation.
Theprocessdoesnothaveappropriateprivilegesanduiddoesnotmatchthe
realuserIDorthesavedset-user-ID.
EXAMPLES
None.
APPLICATIONUSAGE
None.
RATIONALE
Thevariousbehaviorsofthesetuid()andsetgid()functionswhencalledby
non-privilegedprocessesreflectthebehaviorofdifferenthistoricalimplementations.
Forportability,itisrecommendedthatnewnon-privilegedapplicationsusethe
seteuid()andsetegid()functionsinstead.
Thesavedset-user-IDcapabilityallowsaprogramtoregaintheeffectiveuserID
establishedatthelastexeccall.Similarly,thesavedset-group-IDcapabilityallows
aprogramtoregaintheeffectivegroupIDestablishedatthelastexeccall.
ThesecapabilitiesarederivedfromSystemV.Withoutthem,aprogrammighthavetorun
assuperuserinordertoperformthesamefunctions,becausesuperusercanwriteonthe
user’sfiles.Thisisaproblembecausesuchaprogramcanwriteonanyuser’sfiles,
andsomustbecarefullywrittentoemulatethepermissionsofthecallingprocess
properly.InSystemV,thesecapabilitieshavetraditionallybeenimplementedonlyvia
thesetuid()andsetgid()functionsfornon-privilegedprocesses.Thefactthatthe
behaviorofthosefunctionswasdifferentforprivilegedprocessesmadethemdifficult
touse.ThePOSIX.1-1990standarddefinedthesetuid()functiontobehavedifferently
forprivilegedandunprivilegedusers.Whenthecallerhadtheappropriateprivilege,
thefunctionsetthecallingprocess’realuserID,effectiveuserID,andsaved
set-userIDonimplementationsthatsupportedit.Whenthecallerdidnothavethe
appropriateprivilege,thefunctionsetonlytheeffectiveuserID,subjectto
permissionchecks.Theformeruseisgenerallyneededforutilitieslikeloginandsu,
whicharenotconformingapplicationsandthusoutsidethescopeofIEEEStd
1003.1-2001.TheseutilitieswishtochangetheuserIDirrevocablytoanewvalue,
generallythatofanunprivilegeduser.Thelatteruseisneededforconforming
applicationsthatareinstalledwiththeset-user-IDbitandneedtoperformoperations
usingtherealuserID.
IEEEStd1003.1-2001augmentsthelatterfunctionalitywithamandatoryfeaturenamed
_POSIX_SAVED_IDS.Thisfeaturepermitsaset-user-IDapplicationtoswitchits
effectiveuserIDbackandforthbetweenthevaluesofitsexec-timerealuserIDand
effectiveuserID.Unfortunately,thePOSIX.1-1990standarddidnotpermitaconforming
applicationusingthisfeaturetoworkproperlywhenithappenedtobeexecutedwith
the(implementation-defined)appropriateprivilege.Furthermore,theapplicationdid
notevenhaveameanstotellwhetherithadthisprivilege.Sincethesaved
set-user-IDfeatureisquitedesirableforapplications,asevidencedbythefactthat
NISTrequireditinFIPS151-2,ithasbeenmandatedbyIEEEStd1003.1-2001.However,
thereareimplementorswhohavebeenreluctanttosupportitgiventhelimitation
describedabove.
The4.3BSDsystemhandlestheproblembysupportingseparatefunctions:setuid()
(whichalwayssetsboththerealandeffectiveuserIDs,likesetuid()inIEEEStd
1003.1-2001forprivilegedusers),andseteuid()(whichalwayssetsjusttheeffective
userID,likesetuid()inIEEEStd1003.1-2001fornon-privilegedusers).This
separationoffunctionalityintodistinctfunctionsseemsdesirable.4.3BSDdoesnot
supportthesavedset-user-IDfeature.Itsupportssimilarfunctionalityofswitching
theeffectiveuserIDbackandforthviasetreuid(),whichpermitsreversingthereal
andeffectiveuserIDs.Thismodelseemslessdesirablethanthesavedset-user-ID
becausetherealuserIDchangesasasideeffect.Thecurrent4.4BSDincludessaved
effectiveIDsandusesthemforseteuid()andsetegid()asdescribedabove.The
setreuid()andsetregid()functionswillbedeprecatedorremoved.
Thesolutionhereis:
.Requirethatallimplementationssupportthefunctionalityofthesaved
set-user-ID,whichissetbytheexecfunctionsandbyprivilegedcallsto
setuid().
.Addtheseteuid()andsetegid()functionsasportablealternativestosetuid()
andsetgid()fornon-privilegedandprivilegedprocesses.
Historicalsystemshaveprovidedtwomechanismsforaset-user-IDprocesstochangeits
effectiveuserIDtobethesameasitsrealuserIDinsuchawaythatitcouldreturn
totheoriginaleffectiveuserID:theuseofthesetuid()functioninthepresenceof
asavedset-user-ID,ortheuseoftheBSDsetreuid()function,whichwasabletoswap
therealandeffectiveuserIDs.ThechangesincludedinIEEEStd1003.1-2001providea
newmechanismusingseteuid()inconjunctionwithasavedset-user-ID.Thus,all
implementationswiththenewseteuid()mechanismwillhaveasavedset-user-IDfor
eachprocess,andmostofthebehaviorcontrolledby_POSIX_SAVED_IDShasbeenchanged
toagreewiththecasewheretheoptionwasdefined.Thekill()functionisan
exception.Implementorsofthenewseteuid()mechanismwillgenerallyberequiredto
maintaincompatibilitywiththeoldermechanismspreviouslysupportedbytheirsystems.
However,compatibilitywiththisuseofsetreuid()andwiththe_POSIX_SAVED_IDS
behaviorofkill()isunfortunatelycomplicated.Ifanimplementationwithasaved
set-user-IDallowsaprocesstousesetreuid()toswapitsrealandeffectiveuser
IDs,butweretoleavethesavedset-user-IDunmodified,theprocesswouldthenhavean
effectiveuserIDequaltotheoriginalrealuserID,andbothrealandsaved
set-user-IDwouldbeequaltotheoriginaleffectiveuserID.Inthatstate,thereal
userwouldbeunabletokilltheprocess,eventhoughtheeffectiveuserIDofthe
processmatchesthatoftherealuser,ifthekill()behaviorof_POSIX_SAVED_IDS
wasused.Thisisobviouslynotacceptable.Thealternativechoice,whichisusedin
atleastoneimplementation,istochangethesavedset-user-IDtotheeffectiveuser
IDduringmostcallstosetreuid().Thestandarddevelopersconsideredthat
alternativetobelesscorrectthantheretentionoftheoldbehaviorofkill()in
suchsystems.Currentconformingapplicationsshallaccommodateeitherbehaviorfrom
kill(),andthereappearstobenostrongreasonforkill()tocheckthesaved
set-user-IDratherthantheeffectiveuserID.
FUTUREDIRECTIONS
None.
SEEALSO
exec,getegid(),geteuid(),getgid(),getuid(),setegid(),seteuid(),setgid(),
setregid(),setreuid(),theBaseDefinitionsvolumeofIEEEStd1003.1-2001,
<sys/types.h>,<unistd.h>
CHANGEHISTORY
FirstreleasedinIssue1.DerivedfromIssue1oftheSVID.
Issue6
IntheSYNOPSIS,theoptionalincludeoftheheaderisremoved.
ThefollowingnewrequirementsonPOSIXimplementationsderivefromalignmentwiththe
SingleUNIXSpecification:
.Therequirementtoincludehasbeenremoved.Although
wasrequiredforconformingimplementationsofpreviousPOSIXspecifications,it
wasnotrequiredforUNIXapplications.
.Thefunctionalityassociatedwith_POSIX_SAVED_IDSisnowmandatory.ThisisaFIPS
requirement.
ThefollowingchangesweremadetoalignwiththeIEEEP1003.1adraftstandard:
.Theeffectsofsetuid()inprocesseswithoutappropriateprivilegesarechanged.
.Arequirementthatthesupplementarygrouplistisnotaffectedisadded.
以下通过一个典型问题和代码实例来说明UID和EUID的问题。
页:
[1]