Messages in this thread |  | | Date | Tue, 18 Jun 1996 16:23:37 -0400 | From | "Theodore Y. Ts'o" <> | Subject | Re: Proposed change to setre[ug]id() |
| |
From: srb@cuci.nl (Stephen R. van den Berg) Date: Tue, 18 Jun 1996 17:12:21 +0200
These changes make the setre[ug]id() calls more flexible, and functionally compatible with other UNICES (and comes closer to HP/UX, which even has a setresuid() system call).
NO. TRY AGAIN. Your patch is a really bad one! And no, setreuid() *does* mess with the saved setuid with other Unices. I am currently working with people from the NetBSD camp to converge setreuid() with Linux --- interestingly enough, they want to move towards Linux's algorithm, because it's more of the right thing.
I would assert that if this change introduces security problems, then that means that you don't trust the code you wrote in the first place. That already is a bad assumption, so you shouldn't be using this untrustworthy program under suid/sgid privileges anyway.
The problem is that there are programs written assuming old (BSD 4.3 for example) semantics. Most people don't realize whether or not a program was written for BSD 4.3 semantics, and system administrators will just blindly install the old application not realizing that it's unsafe for Linux.
For example, if you have a program which assumes that:
uid = getuid(); setreuid(uid, uid);
will drop all privileges (which is true in BSD 4.3) will no longer be true in in your patches. In fact, there is currently a CERT advisory in preparation for a very popular program (probably present on all virtually all Linux installations) which is related to setuid/saved uid handling --- Linux wasn't affected because of our paranoid setreuid() implementation, but other OS's were affected because they made the same flawed assumption that you made.
- Ted
|  |