> The recent change in semantics of setreuid has broken suidperl, and
> will probably break lots of other things.

really?  perl shouldn't be *using* setreuid, esp. not on POSIX-ish
systems.

> It seems that "setreuid" only sets the euid, and not the ruid anymore.
> Even more to my surprise, comments in the source indicate that this is
> intentional.

that's correct.

> I *very* strongly believe that this change is a bad thing.  What
> happens to the countless programs that do "setreuid(geteuid(), getuid());"
> before and after a critical section?  It's a nightmare.

those programs need to be updated; i'm going to put in a warning
string to indicate this, a la fgets().  And no, don't bother bitching
about it.

We are (aiming to be) a POSIX system.  The POSIX security model
indicates that the real UID is to be changed IF AND ONLY IF the
effective and saved ID's are set at the same time.

That is, setruid() is now bogus, as is setreuid() with any argument
that would set the real uid.

The POSIX security model (with _POSIX_SAVED_IDs, which we support)
works in the following way:

(when i say 'id' i mean 'user or group id'.)
the real id is the real id.
the saved id is the effective id at the time of process execution.
the effective id starts out as the saved id, and is changed by
        setu[ug]id().

the real id is *ONLY* set by set[ug]id(), which also changes
the saved id, and makes the user completely become the id specified.

The saved id is not to be set by anything other than set[ug]id(),
which (as noted) also sets the saved and real id's.

I'd take a look at the new setuid(2) and setreuid(3) man pages;
they explain things a bit more.


There can be serious problems any time setreuid() or setruid()
is used -- most of the rdist security holes, for instance, were
caused by it.


chris

------------------------------------------------------------------------------