Messages in this thread | | | Date | Wed, 12 Aug 1998 09:26:15 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: kill -9 <pid of X> |
| |
On Wed, 12 Aug 1998, Alan Cox wrote: > > There was a real issue further down my email. How do you implement SAK correctly > without kernel support for mode handling ?
By not allowing untrusted users to get access to the screen, perhaps?
In order to get into graphics mode in the first place, you have to have root access. Which means that SAK is a complete non-issue, because if the person who created a graphical trojan horse thing had root, he could have done any number of things instead.
So you have two cases: - graphics under X. You trust the X server, because if you didn't there would be no point anyway - it could do whatever it wanted to you because it has root. So you make a magic SAK keybinding for X, and when X gets that it exits or re-spawns or whatever. - graphics not under X.
For graphics not under X, I told people how to do this a long time ago, and so far nothing has happened. Which makes me think that everybody who complains about the issue either really doesn't care and just wants to be a trouble-maker, or that they are incompetent.
When not under X, rather than having a SVGAlib library and compiling everything to be suid root, you have a root wrapper executable, which is suid, gets the screen changes modes, forks, gets rid of it's suid privileges and does an exec(). You now have a normal user that has access to the screen, but more importantly, you _also_ have a root wrapper you trust. That root wrapper can handle SAK (the kernel knows who it is, because it already had to register as a console switcher process).
(The root wrapper doesn't just go away: it stays in the background, waiting for its child do die, or waiting for the kernel to ask it to switch consoles).
Yes, there may be details that need to be done, but quite frankly, long before any kernel issues even become involved, the thing has to be done properly in user mode. Why are there still people who want to try to change the kernel before they have even considered fixing SVGAlib etc?
Linux isn't a Windows NT where you add cruft in the kernel to get around cruft in user programs.
In short, for me the issue is: - I acknowledge that there may be kernel support lacking for some operations. I wouldn't have any fundamental reasons to dismiss a kernel module that X (or the SVGAlib wrapper) wants to load in order to run safely. - HOWEVER. As far as I'm concerned, before people start to whine to me about kernel support, they'd better have their user land remotely ready for it. The way I see it, the people who whine have not done _anything_ to user land. As such, they are not people I feel I need to talk to - they have shown themselves incapable of the thought "maybe I should fix this in user land first before I complain to the kernel".
Short and sweet: get back to me on this issue when (a) X handles "kill -9" properly (and yes, I agree completely with you that it should do suid(0)+suid(xxx) rather than just suid(0)) and (b) SVGAlib doesn't require that the whole application runs with root privileges.
Before that happens, I don't consider this a kernel issue.
Linus
- 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
| |