>More interestingly, it changes the operation of SAK in two ways:
>(a) It does less, namely will not kill processes with uid 0.
I think this is bad for security.
(I assume you meant euid 0, not ruid 0. Using the real uid
for access control decisions is a very odd thing to do.)
-
To unsubscribe
On Thursday 05 July 2001 21:45, Albert D. Cahalan wrote:
> Oh, cry me a river. You can set the RUID, EUID, SUID, and FUID
> in that same parent process or after you fork().
Okay, I'll bite.
The file user ID is fine, the effective user ID is what the suid bit sets to
root of course, the saved
On Thursday 05 July 2001 21:45, Albert D. Cahalan wrote:
Oh, cry me a river. You can set the RUID, EUID, SUID, and FUID
in that same parent process or after you fork().
Okay, I'll bite.
The file user ID is fine, the effective user ID is what the suid bit sets to
root of course, the saved
More interestingly, it changes the operation of SAK in two ways:
(a) It does less, namely will not kill processes with uid 0.
I think this is bad for security.
(I assume you meant euid 0, not ruid 0. Using the real uid
for access control decisions is a very odd thing to do.)
-
To unsubscribe
Rob Landley writes:
> Off the top of my head, fun things you can't do suid root:
...
> ps (What the...? Worked in Red Hat 7, but not in suse 7.1.
> Huh? "suid-to apache ps ax" works fine, though...)
The ps command used to require setuid root. People would set the
bit by habit.
> I keep
On Monday 02 July 2001 15:10, Hua Zhong wrote:
> -> From Alan Cox <[EMAIL PROTECTED]> :
> > > (a) It does less, namely will not kill processes with uid 0.
> > > Ted, any objections?
> >
> > That breaks the security guarantee. Suppose I use a setuid app to confuse
> > you into doing something ?
>
Rob Landley writes:
Off the top of my head, fun things you can't do suid root:
...
ps (What the...? Worked in Red Hat 7, but not in suse 7.1.
Huh? suid-to apache ps ax works fine, though...)
The ps command used to require setuid root. People would set the
bit by habit.
I keep bumping
On Monday 02 July 2001 15:10, Hua Zhong wrote:
- From Alan Cox [EMAIL PROTECTED] :
(a) It does less, namely will not kill processes with uid 0.
Ted, any objections?
That breaks the security guarantee. Suppose I use a setuid app to confuse
you into doing something ?
a setuid app
-> From Alan Cox <[EMAIL PROTECTED]> :
> > (a) It does less, namely will not kill processes with uid 0.
> > Ted, any objections?
>
> That breaks the security guarantee. Suppose I use a setuid app to confuse
> you into doing something ?
a setuid app only changes euid, doesn't it?
-
To
On Mon, Jul 02, 2001 at 02:16:36PM +0200, [EMAIL PROTECTED] wrote:
> (a) It does less, namely will not kill processes with uid 0.
> Ted, any objections?
What if you have a process running wild as uid 0 (i.e. X server gone bad) that you
need to die *right now*?
--
"Don't dwell on reality; it
>> (a) It does less, namely will not kill processes with uid 0.
>> Ted, any objections?
Alan:
> That breaks the security guarantee. Suppose I use a setuid app to confuse
> you into doing something ?
On second thoughts I agree. Here is the patch without test for p->uid.
Andries
diff -u
>> (a) It does less, namely will not kill processes with uid 0.
>> Ted, any objections?
Alan:
> That breaks the security guarantee. Suppose I use a setuid app to confuse
> you into doing something ?
You confuse me? Unlikely :-)
Indeed, discussion is possible. I think my version is more secure
> (a) It does less, namely will not kill processes with uid 0.
> Ted, any objections?
That breaks the security guarantee. Suppose I use a setuid app to confuse
you into doing something ?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Dear Linus, Alan, Ted, Andrew, all:
(i) Andrew - why don't you add yourself to the CREDITS file?
(then I'll find your email address at the first instead of the second attempt)
(ii) Yesterday I complained about the fact that pressing SAK twice
crashes the kernel (because the close from the first
On Mon, Jul 02, 2001 at 02:16:36PM +0200, [EMAIL PROTECTED] wrote:
(a) It does less, namely will not kill processes with uid 0.
Ted, any objections?
What if you have a process running wild as uid 0 (i.e. X server gone bad) that you
need to die *right now*?
--
Don't dwell on reality; it will
- From Alan Cox [EMAIL PROTECTED] :
(a) It does less, namely will not kill processes with uid 0.
Ted, any objections?
That breaks the security guarantee. Suppose I use a setuid app to confuse
you into doing something ?
a setuid app only changes euid, doesn't it?
-
To unsubscribe from
Dear Linus, Alan, Ted, Andrew, all:
(i) Andrew - why don't you add yourself to the CREDITS file?
(then I'll find your email address at the first instead of the second attempt)
(ii) Yesterday I complained about the fact that pressing SAK twice
crashes the kernel (because the close from the first
(a) It does less, namely will not kill processes with uid 0.
Ted, any objections?
That breaks the security guarantee. Suppose I use a setuid app to confuse
you into doing something ?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
(a) It does less, namely will not kill processes with uid 0.
Ted, any objections?
Alan:
That breaks the security guarantee. Suppose I use a setuid app to confuse
you into doing something ?
You confuse me? Unlikely :-)
Indeed, discussion is possible. I think my version is more secure
and
(a) It does less, namely will not kill processes with uid 0.
Ted, any objections?
Alan:
That breaks the security guarantee. Suppose I use a setuid app to confuse
you into doing something ?
On second thoughts I agree. Here is the patch without test for p-uid.
Andries
diff -u --recursive
20 matches
Mail list logo
