[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABfYdSrbbm_iYmBpDD-Kef8KvSmR7wfDNxQt0L1o0aegONQB2g@mail.gmail.com>
Date: Wed, 6 Jan 2016 09:37:51 -0500
From: Albert Cahalan <acahalan@...il.com>
To: linux-kernel@...r.kernel.org
Subject: 18-year-old bug
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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists