lkml.org 
[lkml]   [1996]   [Nov]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: setresuid()

From: Marek Michalkiewicz <marekm@i17linuxb.ists.pwr.wroc.pl>
Date: Fri, 15 Nov 1996 22:00:13 +0100 (MET)

Our current implementation is slightly different. According to the
HP-UX man page, setresuid() treats all the uids the same way.

setresuid() is allowed if any one of the current uids (ruid/euid/suid)
is 0, or if each of the specified new uids matches at least one of the
current ruid/euid/suid. So if you aren't root, you can swap any two
of the three uids, or even swap all three (they all can be different).

What we're missing is the "if any one of the current uids
(ruid/euid/suid) is 0" test; that was an oversight on my part.

HP-UX also has setresgid(), and we don't. It is similar - if you
aren't root (any of the uids equal to 0), you can swap any of the
three gids.

That seems like a good thing to do.

I think it should be possible to implement the other set*id()
calls only in terms of setres[ug]id(). Maybe even in libc?

Yes; the reason why I sent this into Linus was so that we could move all
of the set*id() into libc. In particular, all of the BSD vs. other
operating systems policy issues can be dealt with by an appropriate
emulation by having setresuid() to provide the kernel support.

One more thing: setresuid() should do "current->dumpable = 0" if
it changes the effective uid (like the other set*id syscalls do).
I think this is necessary to keep /proc/<pid>/fd/* secure (these
files are owned by euid of <pid>).

Yes, that's quite correct. Do you want to supply the patches, or should
I? The changes you've suggested are quite simple, and IMO are the Right
Thing.

- Ted

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