60093 2026-08-05 11:12:19 +0300 pam-securetty.so не готов к существованию kmscon 2026-08-05 11:36:29 +0300 1 1 4 Development Sisyphus login unstable all Linux NEW P5 normal --- 1 arseny placeholder antohami glebfm ldv placeholder qa-sisyphus oldest_to_newest 292282 0 arseny 2026-08-05 11:12:19 +0300 В kmscon (это такой userspace VT) невозможно залогиниться, используя системный /bin/login, потому что в качестве терминала kmscon создаёт pts и сам реализует его мастер-конец; device node, на котором он это делает, не фиксирован, и его нельзя указать в /etc/securetty. 292283 1 arseny 2026-08-05 11:36:29 +0300 Вообще пространство возможных решений довольно обширно, можно сделать разные ходы. Один путь — идти на поклон в ядро и разрешить достаточно привилегированным программам становиться мастер-концами для `/dev/ttyN`. Например, предусмотреть в sysfs управляющие файлики для этого. Программа, открыв такой файлик усл. /sys/devices/virtual/tty/ttyN/u-leader, превратит /dev/ttyN в ведомый конец pts и получит ведущий конец. Позицию соответствующих мейнтейнеров ядра Linux (в первую очередь это GKH) я могу понять так: они не хотели бы ни мешать процессу переноса функциональности VT в userspace-программу, ни помогать этому процессу. "Чем меньше мы будем об этом вообще думать, тем лучше". Или же "поступайте сами, дорогие дистро, как хотите, но желательно не шлите патчей на ядро об этом вообще". Да и преграды, связанные с обратной совместимостью, тут тоже можно предсказать. (Вдруг кто-то успел учредить ioctl-вызовы на /dev/ttyN, управляющие не терминалом, а сеткой знакомест в fbcon или как там её. А как они будут должны себя вести при userspace governor на ttyN? Это надо подумать кому-то, кто помнит о них.) Другой путь — расщепить login pam service так или иначе. Это могут быть разные программы login, разные pam-стеки, вызываемые из *getty+KVT и из kmscon / cage+foot / ... Логика /etc/securetty, таким образом, будет иметь смысл только для терминальных chardevs, ЖЦ которых не связан с процессами и имена которых зарезервированы. Вообще представляется, что pam-securetty as designed в принципе ничему не помогает: трудно себе представить ситуацию, где по какому-нибудь мутному /dev/ttyUSB0, за которым мутные и коварные агенты, мы хотим запретить авторизацию рута, но разрешить, чтобы оттуда нам брутили пароли не-рута, и самого рута тоже безуспешно брутили. Проще не запускать на мутном tty что-либо с достаточными привилегиями для логина или switch user.