18-year-old bug

18-year-old bug

[Albert Cahalan]

This bug was introduced with SE Linux, 18 years ago. People have been
adding hacks to work around it as the bug bites them, but really the
bug ought to be fixed. Signals related to a tty are supposed to come
from the kernel. This got broken for pty devices. We now act as if
the signal is sent from the process on the master side of the pty.
That isn't right; the signal is supposed to come from the tty itself
and thus have a kernel identity.

How to reproduce:

Copy /bin/sleep to /tmp/work and /tmp/fail. Start up xterm, run
/tmp/work in the window, close the window, and see the process gone.
Now repeat that for /tmp/fail, but run "su -" in the window first.
Meanwhile, to view the problem, run this in another window:

ps -Cwork -Cfail -o tty,pid,ppid,tpgid,pgid,sid,ruid,euid,comm

(so like "/tmp/fail 100" or however much time you need)

I first saw the problem when I was maintaining top. People would
run top as root, close the window, and then find that top got stuck
spinning on select. Eventually top was hacked up to work around the
kernel bug, but really we shouldn't have userspace trying to work
around kernel bugs. I tried to fix it back then, but got a bit lost
in the then-new code. Sorry. Since then, I've become insanely busy
with ten kids. I'd really appreciate if somebody could take a shot
at fixing this bug. It seems to have hit a coworker a few months back,
and he is just living with it. (ouch)

Re: 18-year-old bug

[Jeff Merkey]

On 1/6/16, Albert Cahalan <acahalan@gmail.com> wrote:
> This bug was introduced with SE Linux, 18 years ago. People have been
> adding hacks to work around it as the bug bites them, but really the
> bug ought to be fixed. Signals related to a tty are supposed to come
> from the kernel. This got broken for pty devices. We now act as if
> the signal is sent from the process on the master side of the pty.
> That isn't right; the signal is supposed to come from the tty itself
> and thus have a kernel identity.
>
> How to reproduce:
>
> Copy /bin/sleep to /tmp/work and /tmp/fail. Start up xterm, run
> /tmp/work in the window, close the window, and see the process gone.
> Now repeat that for /tmp/fail, but run "su -" in the window first.
> Meanwhile, to view the problem, run this in another window:
>
> ps -Cwork -Cfail -o tty,pid,ppid,tpgid,pgid,sid,ruid,euid,comm
>
> (so like "/tmp/fail 100" or however much time you need)
>
> I first saw the problem when I was maintaining top. People would
> run top as root, close the window, and then find that top got stuck
> spinning on select. Eventually top was hacked up to work around the
> kernel bug, but really we shouldn't have userspace trying to work
> around kernel bugs. I tried to fix it back then, but got a bit lost
> in the then-new code. Sorry. Since then, I've become insanely busy
> with ten kids. I'd really appreciate if somebody could take a shot
> at fixing this bug. It seems to have hit a coworker a few months back,
> and he is just living with it. (ouch)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Point me to the code in kernel and I'll take stab at it.  There are a
bunch of old bugs lurking around the kernel.

Jeff

Re: 18-year-old bug

[Peter Hurley]

On 01/06/2016 06:37 AM, Albert Cahalan wrote:
> This bug was introduced with SE Linux, 18 years ago. People have been
> adding hacks to work around it as the bug bites them, but really the
> bug ought to be fixed. Signals related to a tty are supposed to come
> from the kernel. This got broken for pty devices. We now act as if
> the signal is sent from the process on the master side of the pty.
> That isn't right; the signal is supposed to come from the tty itself
> and thus have a kernel identity.

What problem do you observe and on what kernel version?


> How to reproduce:
> 
> Copy /bin/sleep to /tmp/work and /tmp/fail. Start up xterm, run
> /tmp/work in the window, close the window, and see the process gone.
> Now repeat that for /tmp/fail, but run "su -" in the window first.
> Meanwhile, to view the problem, run this in another window:
> 
> ps -Cwork -Cfail -o tty,pid,ppid,tpgid,pgid,sid,ruid,euid,comm
> 
> (so like "/tmp/fail 100" or however much time you need)
> 
> I first saw the problem when I was maintaining top. People would
> run top as root, close the window, and then find that top got stuck
> spinning on select. Eventually top was hacked up to work around the
> kernel bug, but really we shouldn't have userspace trying to work
> around kernel bugs. I tried to fix it back then, but got a bit lost
> in the then-new code. Sorry. Since then, I've become insanely busy
> with ten kids. I'd really appreciate if somebody could take a shot
> at fixing this bug. It seems to have hit a coworker a few months back,
> and he is just living with it. (ouch)