From owner-freebsd-hackers Fri Aug 17 1:24:53 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from ringworld.nanolink.com (dialmess.nanolink.com [217.75.135.246]) by hub.freebsd.org (Postfix) with SMTP id D865537B406 for ; Fri, 17 Aug 2001 01:24:43 -0700 (PDT) (envelope-from roam@ringlet.net) Received: (qmail 20355 invoked by uid 1000); 17 Aug 2001 08:23:22 -0000 Date: Fri, 17 Aug 2001 11:23:22 +0300 From: Peter Pentchev To: Hans Zaunere Cc: freebsd-hackers@freebsd.org Subject: Re: Signal Handling Message-ID: <20010817112322.C556@ringworld.oblivion.bg> Mail-Followup-To: Hans Zaunere , freebsd-hackers@freebsd.org References: <20010813160932.30924.qmail@web12801.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010813160932.30924.qmail@web12801.mail.yahoo.com>; from zaunere@yahoo.com on Mon, Aug 13, 2001 at 09:09:32AM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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