lkml.org 
[lkml]   [1996]   [Jun]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: Proposed change to setre[ug]id()
H. Peter Anvin <hpa@zytor.com> wrote:
>By author: srb@cuci.nl (Stephen R. van den Berg)
>> "Theodore Y. Ts'o" <tytso@MIT.EDU> wrote:
>> >There are two problems; one is the one you pointed out, and the other is
>> >programs which drop the setuid bits, thinking they are then secure, and
>> >then start doing unsafe things like using gets() and statically-sized
>> >buffers on the stack.

>> Hmmm..., indeed, and then construct a setuid() system call.
>> Well, in that light, the current code looks just fine as it is.

>I have only one comment: dlopen().

>Just because you're in the same process (no exec) doesn't mean the
>code comes from the same file.

It is quite unlikely that programs written with BSD 4.3 semantics in
mind, make use of dlopen() (I don't remember BSD 4.3 supporting anything
like that).

>If we want to emulate HP/UX's setresuid() facility, then let's
>implement a setresuid() call [maybe that should be setresfuid()], but
>don't break the current setreuid() implementation -- ESPECIALLY not
>since it would make secure programs suddenly insecure!

Yes, well, we already agreed on that point. IMHO, it would have indeed
been a lot easier/better if Linux simply would have supported something
like the setresuid() call and that the rest would have been done in
compatibility libraries (as someone else suggested).
--
Sincerely, srb@cuci.nl
Stephen R. van den Berg (AKA BuGless).

"Good moaning!"


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