Re: [leafnode-list] [ANNOUNCE:] leafnode-1.9.12

[Matthias Andree <ma@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

tmcd@xxxxxxxx (Timothy A. McDaniel) writes:

> In another note, someone suggested sending a KILL signal,
> as would be done by

>      kill -9 (pid)

raise(SIGKILL), evidently. You don't fork/exec*() if you want to commit
suicide. Or rather signal(getpid(),9) to prevent libcalls and use
syscalls directly.

> I am vehemently opposed to that.  Too many people use SIGKILL
> as a first resort instead of a last resort.  

Your opinion does not matter. The code needs to be fixed, and the
fragment shown by Cornelius is not appropriate for proper code.  

Suicide is the most reasonable among the unreasonable ways out.

Rationale: After an overflow, you don't know what you damaged. There is
no way to recover, and it is harmful to even try, even SIGKILL may not
work any more. There is NO ALTERNATIVE to NOT USING that code fragment
and get a real length-limited snprintf instead. You may happen to cross
page boundaries overwriting things, in that case, the kernel will send
SIGSEGV anyways which is usually not handled by the program, so it
eventually leads to the kill anyhow.

> The problem is that programs can't catch that signal.  

Correct, that's why I chose that. You must not play games like Russian
Roulette on corrupt programs.

> Thus, if it has a crucial file open and partially modified, then a
> KILL kills it instantly, possibly leaving the file in an inconsistent
> state.

Since the process can be KILLed at any time (be it by power outage, the
machine shutting down, hardware failure), the software HAS to be
designed in a way that it does not leave files in an inconsistent state
that it cannot automatically and safely regenerate upon next
start. Violating this standard is playing games with your data.

This boils down to not modifying and overwriting those files in situ[1],
but writing data to some.file.new, closing, fsync()'ing and only then
link it into the appropriate place.

[Note: It may also be needed to fsync() the parent directory on Linux
(see the corresponding discussions on qmail and Postfix mailing lists
for details).]

> If leafnode keeps a signal handler around to cleanly terminate,
> then KILL should definitely not be used.

Overflowing buffers may have trashed your signal handler. There is no
alternative to KILL except for better code that does not fall into this
overflow trap it has armed itself.



[1] ever wondered why you lost your Netscape bookmarks, address book or
preferences? This usually coincides with "disk full" that Netscape
cannot handle since it overwrites its old files directly rather than
using the safe method. This is annoying and avoidable. 

-- 
Matthias Andree

                Where do you think you're going today?

-- 
leafnode-list@xxxxxxxxxxxxxxxxxxxxxxxxxxxx -- mailing list for leafnode
To unsubscribe, send mail with "unsubscribe" in the subject to the list