Subject: Re: setreuid semantics changed
To: Keith Moore <moore@cs.utk.edu>
From: Chris G. Demetriou <cgd@postgres.Berkeley.EDU>
List: current-users
Date: 04/08/1994 10:40:06
> If I understand your description right, it sounds as if the POSIX model is
> incompatible with both of the old ways of switching between two euid's:
> either using setreuid() to swap uid<->euid,

it's definitely incompatible with that; you're not allowed to set ruid
w/o also setting euid and svuid's.  However, you'll note that setreuid
is coded in such a way that if you want to switch between effective
uid's, it should still work.

> or using setuid() to switch from
> uid=0 to some other uid and being able to switch back later because the
> 'saved' uid remembers that you are really root.

in posix (with _POSIX_SAVED_IDs), you're supposed to use seteuid()
to do that; i guess that's incompatible, too.

> I can understand wanting to be POSIX compatible, but is it necessary to
> break binary compatibility?  Especially on sparc or other "legacy" systems?
> (Could there be a kernel option to allow the old behavior?)

If people maintaining the 'compat' code wish to do this, they're
more-or-less free to, though i'd advise against it, because of
the security issues.  (i'd argue that most things which use setreuid()
are probably broken.)

No, i'm not going to add a 'general' kernel option for this.

> As for the setreuid() routine, if it's not going to work as expected, I'd
> rather see it removed entirely from libc.  That way, when porting code, you
> find out a link time rather than at run time.

nobody who's writing POSIX code should be using setreuid().  If
they're writing POSIX code and they use it, well, "we provide the
rope."  If they're *intentionally* using it, on POSIX systems, they
we should probably provide a GUN.


cgd

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