Вообще пространство возможных решений довольно обширно, можно сделать разные ходы.


Один путь — идти на поклон в ядро и разрешить достаточно привилегированным программам становиться мастер-концами для `/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.