Date: Fri, 16 Jan 2004 13:34:18 -0800 From: David Schultz <das@FreeBSD.ORG> To: Robert Watson <rwatson@FreeBSD.ORG> Cc: arch@FreeBSD.ORG Subject: Re: Signal delivery to kernel threads/processes? Message-ID: <20040116213418.GA27542@VARK.homeunix.com> In-Reply-To: <Pine.NEB.3.96L.1040116135741.94620D-100000@fledge.watson.org> References: <Pine.NEB.3.96L.1040116135741.94620D-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jan 16, 2004, Robert Watson wrote: > Bill Paul raised an interesting question with me recently -- he observed > that a userspace process running with root privileges could deliver a > signal to a kthread, and that this might produce undesired behavior. I > was sure that, at some point, we had a check disallowing this, but I don't > see it in either RELENG_4 or HEAD. Do we rely on the ability to > send/receive signals to interrupt kthreads, that we know of? While the > signal delivery itself doesn't make sense, waking up a tsleep() with > PCATCH could well be useful behavior. Should a kthread have to declare if > it wants to receive interruptions? Given plans, at some point, to make > kthreads be real threads, and be part of a kernel process, that would > raise some challenges for code relying on the ability to be interrupted > with a signal in kernel space, as signals generated by kill() are > targetted at processes, not threads. > > Any thoughts? It's tempting simply to add the following to cr_cansignal() > to at least disallow sourcing the signals in userspace: > > if (p->p_flag & P_SYSTEM) > return (EPERM); I believe nfsd needs to accept signals so that it can be shut down. But now that I think about what you've said, I wonder what this implies for system processes such as aiod that switch their credentials to those of the request they are processing. It would seem that in the window during which they have the ordinary user's uid, they could be killed by an ordinary user. I hope there's already some safeguard against this that I don't know about...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040116213418.GA27542>