jfh@rpp386.cactus.org (John F. Haugh II) (07/29/90)
From: jfh@rpp386.cactus.org (John F. Haugh II) Peter Jeffe has managed to convince me that there is something flawed in my reading of 4.2.2, and the associated pieces of 1003.1 related to the feature test macro _POSIX_SAVED_IDS. The rationale, in B.4.2.2, claims that this functionality is derived from System V and is designed to permit the application to toggle between the effective ID of the process and the real ID of the process creator. The conflict between 4.2.2.2 and System V setuid is that System V states "If the effective user ID of the calling process is super-user, the real user (group) ID and effective user (group) ID are set to uid (gid)." and 4.2.2.2 states "(1) If the process has appropriate privileges, the setuid() function sets the real user ID, effective user ID, and the saved set-user-ID to uid." The first problem is that a program which is set-user-ID to an ID other than super-user will behave quite differently when executed by root. The first execution of "setuid (real_uid)" will change the effective user ID to a process which "has appropriate privileges" so that the second execution of "setuid (effective_uid)" will permanently change the process back to "effective_uid". The second problem relates to processes which are set-user-ID to super-user. The first execution of "setuid (real_uid)" is going to permanently change the IDs so that the process can never switch back to the original saved set-user-ID. Contrary to the rationale, this behavior does not permit the application to toggle between the real and saved set-user-ID unless both are not the super-user's ID. So, how does an application toggle between a non-super user and a super-user? -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org Volume-Number: Volume 20, Number 148
rml@hpfcdc.fc.hp.com (Bob Lenk) (08/01/90)
From: Bob Lenk <rml@hpfcdc.fc.hp.com> In article <404@usenix.ORG>,jfh@rpp386.cactus.org (John F. Haugh II) says: > The conflict between 4.2.2.2 and System V setuid is that System V states > > "If the effective user ID of the calling process is super-user, > the real user (group) ID and effective user (group) ID are set > to uid (gid)." > > and 4.2.2.2 states > > "(1) If the process has appropriate privileges, the setuid() > function sets the real user ID, effective user ID, and the > saved set-user-ID to uid." The behavior required in 4.2.2.2 is understood to be the actual behavior of System V (at least Release 2, assuming that appropriate privilege means super-user). > The first problem is that a program which is set-user-ID to an ID other > than super-user will behave quite differently when executed by root. Correct. > The second problem relates to processes which are set-user-ID to super-user. Correct. Contrary to the rationale, this behavior does not permit the application to toggle between the real and saved set-user-ID unless both are not the super-user's ID. I'm not sure if this is contrary to the rationale, though it is more complete. The third paragraph of B.4.2.2 (top of page 236) explains that the behavior for privileged processes is different. The problem is that setuid() and setgid() are overloaded with two behaviors, and the behavior is selected by privilege (traditionally uid). The fact that a portable POSIX application has no way to determine whether it is privileged makes this even worse. > So, how does an application toggle between a non-super user and a super-user? The only ways I know of are to use non-(POSIX/SysV) features or to use two processes. The current draft of the 1003.1a supplement (formerly 1003.1b, *not* the 1003.1-1990 revision) introduces the functions seteuid() and setegid() to address this. Bob Lenk rml@hpfcla.hp.com hplabs!hpfcla!rml Volume-Number: Volume 20, Number 152
guy@auspex.uucp (Guy Harris) (08/02/90)
From: guy@auspex.uucp (Guy Harris) >The rationale, in B.4.2.2, claims that this functionality is derived from >System V It is. >and is designed to permit the application to toggle between the >effective ID of the process and the real ID of the process creator. It, like the S5 functionality it is derived from, does so as long as the process isn't set-UID "root". POSIX just inherits S5's deficiencies here. >The conflict between 4.2.2.2 and System V setuid is that System V states > > "If the effective user ID of the calling process is super-user, > the real user (group) ID and effective user (group) ID are set > to uid (gid)." That may be what the SVID *states* (or Issue 2 states, anyway; our copy of volume 1 has disappeared), and is what the S5R3 documentation states, but it ain't what System V *does*. What System V *does* is: >and 4.2.2.2 states > > "(1) If the process has appropriate privileges, the setuid() > function sets the real user ID, effective user ID, and the > saved set-user-ID to uid." ...precisely that. If you do "setuid(uid)" when the effective user ID is super-user, the saved set-user ID, as well as the real and effective UIDs, are set to "uid". There's no conflict between what AT&T's S5 implementation does, and what POSIX specifies. There may be a conflict between what the SVID, Issue 2, specifies, and what POSIX specifies, but that means there's a conflict between what the SVID, Issue 2, specifies and what System V does, too. (Remember, this is UNIX; the documentation isn't the up-to-date spec for what the system does, the code is.) In fact, the Third Edition of the SVID finally admits that; the wording is the same as POSIX. The S5R4 documentation also admits the way S5 has worked since saved set-user IDs were first introduced. >Contrary to the rationale, this behavior does not permit the application >to toggle between the real and saved set-user-ID unless both are not the >super-user's ID. So, how does an application toggle between a non-super >user and a super-user? The author of the application lobbies one or more of POSIX and AT&T/UI to specify or implement "seteuid()", a call that takes one argument and sets the effective user ID, and *ONLY* the effective user ID, to the value of that argument, even if the process has appropriate privileges. Without a call like that - which some systems with saved set-user IDs, such as SunOS 4.x, have, and which System V Release 4 may even have, but without documentation - you're screwed. Volume-Number: Volume 20, Number 154