[lkml]   [1998]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 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
    - 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.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:44    [W:0.022 / U:100.400 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site