Date: Fri, 17 Aug 2001 11:23:22 +0300 From: Peter Pentchev <roam@ringlet.net> To: Hans Zaunere <zaunere@yahoo.com> Cc: freebsd-hackers@freebsd.org Subject: Re: Signal Handling Message-ID: <20010817112322.C556@ringworld.oblivion.bg> In-Reply-To: <20010813160932.30924.qmail@web12801.mail.yahoo.com>; from zaunere@yahoo.com on Mon, Aug 13, 2001 at 09:09:32AM -0700 References: <20010813160932.30924.qmail@web12801.mail.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Aug 13, 2001 at 09:09:32AM -0700, Hans Zaunere wrote: > > In a program that I am working on, I've decided to > catch signal 15, which then calls execl() in the > handler to reload the program from the on-disk binary. > I am able to send it the signal, it reloads, and > works fine. However I could not send the signal again > and have the program respond. I then learned, with > some help, that the signal needs to be unblocked after > each call. It now works as intended. > > However in reading about this, in Steven's Advanced > Programming in the UNIX Environment, he states: > "Naturally a signal that is being caught by a process > that calls exec cannot be caught in the new program, > since the address of the signal-catching function in > the caller probably has no meaning in the new program > file that is execed. Page. 273) > > This makes sense to me, however doesn't seem to be the > case. Three questions: > > 1) Why, in the first place, does a signal become > blocked after it is recieved? Why does the kernel > want to do this? Mainly compatibility - it was done this way in some oold Unixen. The sigaction(2) syscall gives you much more control over how your handlers are called/reset/etc. > 2) If a 10k binary is running, the signal is sent, and > the program is reloaded from disk, but is 100k (or 1k > even) how does the signal handling function get > called, taking into account what Stevens says. Steven > states that the sigmask remains for calls across exec, > so wouldn't the wrong address to the handler function > be used? The sigmask remains, but not the handlers themselves. Look at the execve(2) manual page - it explains exactly what is done to both signal handlers and the signal mask - the part about blocked signals is the one that talks about the signal mask. > 3) Is my using of exec, in fact, the best way to > reload the program on the fly, from within itself? > What would be the best, robust, way to do this in the > future? Executing your own image is a good way to do it. It does have some drawbacks, but it is a good way. I hope that when you exec something, you are really certain that it is your actual program that you are executing, and not just argv[0]. Otherwise, a malicious user might start your program with a different argv[0] setting (all exec*() functions allow this), then send a 'reload' signal/command/whatever, and have your program execute something else, possibly with elevated privileges. G'luck, Peter -- If I were you, who would be reading this sentence? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010817112322.C556>