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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
