How to disable Ctrl-C during init (initial ramdisk / normal init)

[Michael S. Zick]

On Tue May 23 2006 10:46, Rich Felker wrote:
> On Tue, May 23, 2006 at 10:22:53AM -0500, Michael S. Zick wrote:
> > On Tue May 23 2006 10:11, Rich Felker wrote:
> > > On Tue, May 23, 2006 at 08:09:15AM -0500, Michael S. Zick wrote:
> > > > > Or perhaps there is a way to disable stdin on console during critical 
> > > > > phase of init?
> > > > > 
> > > > 
> > > > Keep the customer away from console.  Like don't wire it out of the box.
> > > 
> > > I disagree with this principle. It's certainly reasonable to have a
> > > kiosk or other type of system where untrusted users can access the
> > > keyboard, and not want them to be able to perform privileged
> > > operations using it!
> > > 
> > 
> > I was unclear - don't wire out /dev/console.
> > 
> > Does not mean you do not bring out other devices for the attachment
> > of keyboards accepting user input.
> > 
> > That is: Let init run on /dev/console and allow physical access by
> > users on /dev/something_else.
> 
> While there are some additional semantics, /dev/console is the same as
> /dev/tty0 which is in turn the same as the currently selected virtual
> terminal. Unless of course you mean to connect /dev/console to a
> serial device, which depends on actually having a serial device. All
> of this sounds incredibly stupid to me. NO device, whether local,
> remote, connected, unconnected, etc. should unconditionally allow
> random people to interfere with system processes. It's just bad,
> insecure system design.
> 

That is exactly what I said. Run the init process on a secure something.

Remove the access by "random people" from the init process.  Your choice
of method of implementation.

Thank you for making it clearer than I could word it.

Mike