POSIX Saved-Set-IDs v. System V

[Bob Lenk]

From:  Bob Lenk <rml at hpfcdc.fc.hp.com>

In article <404 at usenix.ORG>,jfh at 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 at hpfcla.hp.com
		hplabs!hpfcla!rml


Volume-Number: Volume 20, Number 152