[lkml]   [1996]   [Jun]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Proposed change to setre[ug]id()
   From: (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

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

 \ /
  Last update: 2005-03-22 13:37    [W:0.145 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site