> In article <Pine.HPP.3.91.980811192452.22974F-100000@gaia.ecs.csus.edu>,
> Jon M. Taylor <taylorj@ecs.csus.edu> wrote:
> >>
> >> That's not the kernel's job.
> >
> > Whose job is it then? X's? X cannot do the job properly because
> >it can be killed and leave the hardware in an unknown state.
>
> Jon, why do you continue to maintain this, when you have been told that
> you're wrong?
>
> The X server can avoid even kill -9 from a normal user. As it stands,
> it doesn't do that, and I personally think it's a bug in X. But it's
> not a kernel problem - X could make sure (by doing a "setuid(0)" to
> renounce all use privileges) that nobody can kill it but root.
>
> (And by the time you have a root that sends it a signal, you have a root
> that could have killed the machine in easier ways, so don't even bother
> claiming that it makes any difference).
May I therefore ask (as devil's advocate, please realize) why the kernel
prevents init from receiving unwanted signals? Surely there is no reason
root shouldn't be able to SIGKILL init, as you "could have killed the
machine in easier ways", and we seem to be talking about the same level of
mistake (accidentally killing the wrong process).
I would like to understand your reasoning. Root certainly _can_ kill the
machine, but that is no reason to make it easy. See init, and the fact
that reboot() requires magic numbers.
-- Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html