On Mon, 6 Aug 2001, David Christensen wrote:

> I'm looking for a way to prevent a user from generating a SIGINT by
> pressing the CTRL-C key.  I know this can be done with the bash "trap"
> command or the "stty" command but this only works when a shell is
> running.  How can I guarantee that a user can't generate SIGINT at any
> time?  Possible a kernel modification to block that signal?

I'd be very wary of modifying the kernel for something such as this.  For
one thing, if you prevent all SIGINTs from being sent, then you're likely
to break a lot of things (like ctrlaltdel, but maybe that's OK for your
application).  The alternative is to special case your application, which
is ugly.

Can you be more specific of what you're trying to accomplish?  In general,
your application sets what handler will respond to a signal.  ('trap' in
bash is an interface to this.)  See 'man sigaction'

Do you need to prevent everything from *sending* your process SIGINT, or
is it OK to prevent your process from *receiving* SIGINT?  To make
your app ignore SIGINT, the first thing your code should do is use
appropriate calls to sigaction().

If you're worried about a race condition (like if something sends SIGINT
to your application before it can call sigaction()), then you could just
modify init to call sigaction to ignore SIGINT after it fork()s but before
it exec()s.  So as soon as the process starts it ignores all INTs.  To me
that solution is more maintainable than modifying the kernel (but maybe
not as fun!)

Question for the group: what mechanism is it that maps the keypress CTRL-C
to SIGINT?  Is it the TTY handler, or is it the controlling process
(usually the shell)?  Or something else?

--Jeremy

Jeremy Impson
Sr. Associate Network Engineer
Advanced Technologies Department
Lockheed Martin Systems Integration
email: [EMAIL PROTECTED]
phone: 607-751-5618
fax:   607-751-6025


--
To unsubscribe from this list, send a message to [EMAIL PROTECTED]
with the command "unsubscribe linux-embedded" in the message body.
For more information, see <http://waste.org/mail/linux-embedded>.

Reply via email to