linux-kernel - Re: Visible Ctrl-C in latest kernels

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <48B2EDC2.1020608@davidnewall.com>
Date:	Tue, 26 Aug 2008 03:07:06 +0930
From:	David Newall <davidn@...idnewall.com>
To:	Willy Tarreau <w@....eu>
CC:	Chris Frey <cdfrey@...rsquare.net>, Joe Peterson <joe@...rush.com>,
	Vegard Nossum <vegard.nossum@...il.com>,
	linux-kernel@...r.kernel.org
Subject: Re: Visible Ctrl-C in latest kernels

Willy Tarreau wrote:
> I would not be surprized that it is what has caused delays for Ctrl-C
> to take effect for some of us. As discussed in another thread on the
> subject, the problem was relatively recent and not easy to reproduce.
>   

I don't think so.  Joe Peterson raised A line of enquiry, which looked
quite promising to me, in
http://marc.info/?l=linux-kernel&m=121502197008293.  He observed weird
behaviour with pgrp, and that doesn't seem to have been explored
adequately.  I think it's worth highlighting that the code which sends
the signal is the following snippet, from n_tty.c:

    if (tty->pgrp)
            kill_pgrp(tty->pgrp, signal, 1);

I wonder if pgrp has a value different than we expect?

> Now we have a patch to try to revert if/when we finally get a reproducible
> case.

I had an idea; it didn't work out as I expected, but it did produce a
result that I can't immediately explain; and it might be relevant.  The
following program, when executed in background (./testprogram &) stops
at tcsetpgrp(), which is fine; and if then continued (fg), it is immune
to the interrupt, quit and suspend keys.  However, it is not immune to
those keys if executed in foreground (./testprogram).  As said, I can't
immediately explain this, and it seems like it might be important...

#include <unistd.h>
#include <sys/types.h>
#include <stdio.h>
#include <stdlib.h>
#include <signal.h>

main() {
        int i;
        pid_t pid = getpid();
        pid_t ppid = getppid();
        int tty = open("/dev/tty", 0);
        if (tty == -1) {
                perror("/dev/tty");
                exit(1);
        }
        printf("pid %d (pgrp %d), ppid %d (pgrp %d), pgrp %d\n", pid, getpgid(pid), ppid, getpgid(ppid), tcgetpgrp(tty));

        if (tcsetpgrp(tty, ppid) == -1) {
                perror("tcsetpgrp");
                exit(2);
        }

        for (i = 0; i < 5; i++) {
                sleep(1);
                write(1, ".", 1);
        }
        sleep(1);
        write(1, "\n", 1);

        return 0;
}

--
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/