On Wed, 15 Aug 2007, Wojciech Purczynski wrote:
>
> > This doesn't change anything in what I said previously. If the sender's
> > EUID or RUID equals to any of SUID or RUID of the victim or the sender
> > process is root, the sender can send any signal to the victim; if none
> > of those conditions are met, it obviously can't, no matter how and what
> > signal it sends. For details look at check_kill_permission() and
> > group_send_sig_info() in kernel/signal.c and reparent_thread() in
> > kernel/exit.c in the kernel source tree (version 2.6.22).
>
> Dan, could you take a closer look at what setuid(0) does? In the beggining
> of setuid manual page you can read that:
>
> setuid sets the effective user ID of the current process.
> If the effective userid of the caller is root, the real
> and saved user ID's are also set.
>
Yes, I knew that before.
> In this case check_kill_permission() returns -EPERM for unprivileged
> parent.
>
You always talked about setuid root process sending PDEATH_SIG to the root
child, didn't you? check_kill_permission() checks current->euid and
current->uid against t->uid and t->suid, where 'current' is the pointer to the
task_struct of the sender, or, in our case, of the dying setuid root process,
and 't' is the pointer to the task_struct of the root child. If one of those
checks succeeds then the entire check_kill_permission() succeeds. current->euid
is in our case 0, t->uid and t->suid are 0 too. So where is the problem?
--
Sincerely Your, Dan.
