> 2) Any places which compare the real and saved IDs to check whether a
> process is still in a set-ID context (e.g. coredump()) must be changed
> to also compare the effective ID.  This does not create any
> unnecessary restrictions when only using the setuid(), seteuid(),
> setgid() and setegid() functions, because the fact that the real and
> saved IDs are the same means that the effective ID must also be the
> same unless your real ID is root (in which case it's arguably a bug
> that we currently allow core dumps).

I'd say that it is, indeed a bug...

Consider the (pretty standard) case where a set-id program reads the
password file (and obtains encrypted passwords), gives up its set-id,
then SEGV's...  if it can dump code: "lose."


cgd