Messages in this thread |  | | From | (Stephen R. van den Berg) | Date | Sun, 16 Jun 1996 18:35:08 +0200 | Subject | Re: BEWARE! Linux seteuid is broken! |
| |
"A.N.Kuznetsov" <kuznet@ms2.inr.ac.ru> wrote: >specify "super-user", so that in POSIX domain setuid() is exactly UNIX >(BSD and SVR4, but not Linux) seteuid().
>> 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!"
|  |