[ On Mon, May 27, 1996 at 11:08:53 (+1000), matthew green wrote: ]
> Subject: Re: setreuid() and setregid() 
>
> the problem with _POSIX_SAVED_IDS is that it does *not*
> allow a setuid non-root program to entirely give up the
> setuid ness.

That's not a problem -- that's a *feature*!  ;-)

A non-privileged process should not be able to give up all traces of its
origins, and thus should not be able to re-set p_ruid and especially not
p_svuid.  (4bsd setreuid() changes p_ruid, but only because it didn't
already have p_svuid for the same purpose -- new implementations could
probably give up this, if implemented very carefully, for sake of the
new policy as I can't imagine anything that might depend upon it)

I'd sure like to understand what people think they'd lose if setuid() et
al were made POSIX compliant.  Does anyone have any practical examples?

> i can remember noticing this not defined some time ago
> (1994ish) and reading up about this in steven's book. i
> remember disagreeing with what steven's said, at the time.

Stevens doesn't say anything disagreeable -- he's just reporting the
facts.  If you wish to disagree, take issue with Research UNIX, and
subsequently the AT&T SVID and/or the DoD (and/or the Canadian DND, or
the French, etc.).

> i really like our current saved userid model. the only
> reason charles is proposing to add setre[gu]id() back is for
> compatibility -- the current interfaces aren't correct and
> can cause problems (perl is one that loses because of this).

What's the point of trying to achieve POSIX compliance if the most
important feature of all (i.e. security policy) is not also compliant
(or at bare minimum compile-time configurably compliant)????

-- 
							Greg A. Woods

+1 416 443-1734			VE3TCP			robohack!woods
Planix, Inc. <woods@planix.com>; Secrets Of The Weird <woods@weird.com>