saved IDs and exec (standard violation?)

[Marcus Brinkmann]

Hi,

I think we have a bug that makes saved IDs to be inherited across exec where
it shouldn't be. This makes the screen program leak the utmp gid into the 
shells,
because it relies on setuid(real_uid) and setgid(real_gid) to get rid off
the saved gid utmp (it is not setuid root, so it is not privileged).

POSIX says on this issue (draft 7, I hope this didn't change), in the docs
about the exec functions:

"If the ST_NOSUID bit is set for the file system containing the new process
image file, then the effective user ID, effective group ID, saved set-user-ID,
and saved set-group-ID are unchanged in the new process image. Otherwise, if
the set-user-ID mode bit of the new process image file is set, the effective
user ID of the new process image shall be set to the user ID of the new process
image file. Similarly, if the set-group-ID mode bit of the new process image
file is set, the effective group ID of the new process image shall be set to
the group ID of the new process image file. The real user ID, real group ID,
and supplementary group IDs of the new process image shall remain the same as
those of the calling process image. The effective user ID and effective group
ID of the new process image shall be saved (as the saved set-user-ID and the
saved set-group-ID) for use by setuid( )."

So, POSIX says:
ST_NOSUID on filesystem set => eff and saved IDs remain the same
ST_NOSUID not set => If file has saved id, set corresponding effective id.

real IDs and suppl group IDs are never changed.

Effective IDs become saved ids.

I think it is this last point that is not true on the Hurd:  the "setgid()"
call in screen sets the effective ID to the real ID, and then the exec
inherits the real, eff, and saved ID instead inheriting the real and
effective ID and setting the saved ID to this effective ID.

I have verified this with a small program, owned by marcus, group utmp, SGID
bit set, which prints the gid and egid (marcus and utmp), changed the egid
to marcus, and then does a fork+exec to start a second program.
This second program is owned marcus.marcus and not SGID.  It shows that
the real ID and eff ID of this second process are marcus, but the
process can change the EGID to utmp.

The same is verified by screen, where running ids shows that the saved group
ID (the second in the available gids) is actually utmp rather than the user
I am running screen as.

It seems to be merely an issue of the default behaviour in glibc, and not a
security issue in general (except of course that standard Unix programs will
leak saved IDs), and also a violation of the POSIX standard.  But it might
be that I am misreading the standard.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann              GNU    http://www.gnu.org    marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de