Path: utzoo!attcan!uunet!usenix!std-unix
From: guy@auspex.uucp (Guy Harris)
Newsgroups: comp.std.unix
Subject: Re: POSIX Saved-Set-IDs v. System V
Message-ID: <414@usenix.ORG>
Date: 2 Aug 90 00:47:33 GMT
References: <404@usenix.ORG>
Sender: std-unix@usenix.ORG
Reply-To: std-unix@uunet.uu.net
Organization: Auspex Systems, Santa Clara
Lines: 60
Approved: jsq@usenix (Moderator, John Quarterman)

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