From: edward_at_paradigm4.com.au
Date: Mon Jan 07 2002 - 15:05:16 EST
Hi,
Blocking signals sent to a process based only on s_context value of the current pid causes problems.
One of them is not being able to use ^C or ^Z when you enter a vserver context.
Another side affect is not being able to receive SIGURG from the tcp_input module.
The patch below attempts to restore the correct behavior by allowing
privileged aka kernel code ( e.g. console driver ) to send signals to a process
no matter what the security context of the current pid happens to be.
Signals originated from userspace would still undergo s_context check.
hth
Ed
--- linux-2.4.17/kernel/signal.c.orig Mon Jan 7 02:23:11 2002
+++ linux-2.4.17/kernel/signal.c Tue Jan 8 04:24:49 2002
@@ -592,7 +592,7 @@
retval = -ESRCH;
read_lock(&tasklist_lock);
for_each_task(p) {
- if (p->pgrp == pgrp && p->s_context == current->s_context) {
+ if (p->pgrp == pgrp && ((unsigned long)info==1||p->s_context == current->s_context) ) {
int err = send_sig_info(sig, info, p);
if (retval)
retval = err;
@@ -639,8 +639,20 @@
read_lock(&tasklist_lock);
p = find_task_by_pid(pid);
error = -ESRCH;
- if (p && p->s_context == current->s_context)
- error = send_sig_info(sig, info, p);
+ if (p)
+ switch((unsigned long)info) {
+ case 0:
+ if(p->s_context == current->s_context)
+ error = send_sig_info(sig, info, p);
+ break;
+ case 1:
+ error = send_sig_info(sig, info, p);
+ break;
+ default:
+ if( info->si_code == SI_KERNEL || p->s_context == current->s_context )
+ error = send_sig_info(sig, info, p);
+ break;
+ }
read_unlock(&tasklist_lock);
return error;
}
This archive was generated by hypermail 2.1.4 : Mon Aug 19 2002 - 12:01:00 EDT