El mar., 25 feb. 2020 a las 6:08, Jonathan de Boyne Pollard escribió:
>
> Laurent Bercot:
> > Of course, but once the fd is closed, /dev/console should not have
> > any impact on the process, so would a kbrequest still reach it?
>
> Yes.
Also, I tested it :) I added an open2("/dev/tty0", O_RDONLY |
O_NOCTTY) + ioctl() + fd_close() sequence to s6-linux-init.c right
after the reboot(RB_DISABLE_CAD) call, specifying SIGQUIT as the
argument of the KDSIGACCEPT ioctl (to use a signal 'divertable' by
s6-2.9.0.1's s6-svscan), and the SIGQUIT handler does get called
indeed when I press Alt + Up Arrow.
The file descriptor specified in the ioctl() call, as far as I can
tell, is only used by the kernel to check permissions. The ioctl is
allowed if the FD corresponds to the process' control terminal, or if
the process has CAP_KILL or CAP_SYS_TTY_CONFIG capabilities. But the
kernel just seems to record the PID of the invoking process and the
requested signal number. (vt_ioctl() in drivers/tty/vt/vt_ioctl.c).
> First: This is a kernel virtual terminal thing not a console
> thing. Strictly speaking, it is doing it wrongly to access it through
> the console device, which is not necessarily a KVT.
Yeah, I overlooked this. I suppose it'll work on /dev/console as long
as it is a kernel virtual terminal, but it won't always be the case.
sysvinit and systemd use /dev/tty0 for the ioctl (and sysvinit falls
back to its standard input if that fails), so I used that for the
(second) test.
G.
Received on Tue Feb 25 2020 - 18:38:15 UTC
This archive was generated by hypermail 2.3.0
: Sun May 09 2021 - 19:44:19 UTC