Messages in this thread | | | Subject | Re: 18-year-old bug | From | Peter Hurley <> | Date | Thu, 7 Jan 2016 13:37:13 -0800 |
| |
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)
| |