>> I deliberately had setreuid() set the saved-uid because this
>> would seem to avoid certain security problems. See the comments in
>> kernel/sys.c for my justification for doing this.
>Linux setreuid is broken too!!!
No, it is not. setreuid() comes out of the old BSD world. They don't know
anything about saveduids there. I would concur though that the setreuid()
behaves differently than other OSes that handle saved uids as well.
If, however, one were to change the source below to simply avoid the
null-operation setreuids() (by simply changing the libc implementation
to check if it *is* a null operation before actually calling the
kernel function)...
>main() {
> int uid = getuid();
> printf("%d %d\n", getuid(), geteuid());
> seteuid(uid);
>
> /* key_call */
> printf("%d %d\n", getuid(), geteuid());
#if 0
> setreuid(uid,uid);
#endif
> printf("%d %d\n", getuid(), geteuid());
#if 0
> setreuid(uid,uid);
#endif
> printf("%d %d\n", getuid(), geteuid());
> /* key_call returns */
>
> seteuid(0);
> printf("%d %d\n", getuid(), geteuid());
>}
>BSD/SVR4 (2018 is my uid):
>2018 0
>2018 2018
>2018 2018
>2018 0
You'll notice that your Linux box produces the exact same results.
>Emulation of seteuid(.) by setreuid(-1,.) in libc is another bug.
>Moreover, it is impossible to emulate BSD/SVR4 (well, not POSIX :-))
>seteuid() without kernel support.
Note that you're talking about new BSD behaviour. But, indeed, Linux
cannot provide the same functionality because the setreuid() call
insists on touching the saveduid most of the time.
--
Sincerely, srb@cuci.nl
Stephen R. van den Berg (AKA BuGless).
"And now for something *completely* different!"