POSIX Saved-Set-IDs v. System V

[John F. Haugh II]

From:  jfh at 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 at rpp386.cactus.org

Volume-Number: Volume 20, Number 148