Старый механизм AT&T System 5 для псевдо-терминальных ведомых устройств заключался в том, что они были обычными постоянными узлами символьных устройств под /dev. Было мультиплексорное ведущее устройство по адресу /dev/ptmx. Старый механизм 4.3BSD для псевдотерминальных устройств -имел параллельные пары обычных постоянных узлов главного и подчиненного устройств под /dev.

В обоих случаях это означало, что файлы подчиненных устройств сохраняли свое последнее право собственности и разрешения после закрытия последнего файлового дескриптора. Отсюда эволюция функции grantpt()для фиксации владельца и прав доступа к файлу ведомого устройства после того, как (re -используемый )псевдо-терминал -был (re -)выделен.

Это, в свою очередь, означало, что было окно, когда программа устанавливала повторно -используемый псевдо-терминал -между open()и grantpt(), где любой, кто ранее владел ведомым устройством, мог проникнуть внутрь. и открыть его, потенциально получив доступ к чужому терминалу. Отсюда идея псевдо-оконечных ведомых символьных устройств, начинающихся в заблокированном состоянии, в котором они не могут быть открыты, и разблокируемых с помощью unlockpt()после успешного выполнения grantpt().

С годами выяснилось, что в этом нет необходимости.

В настоящее время файлы ведомых устройств не являются постоянными, потому что ядро ​​/devсоздает и уничтожает вещи в себе. Действие открытия ведущего устройства либо сбрасывает разрешения и права собственности ведомого устройства,или напрямую создает файл ведомого устройства заново (, в последнем случае файл ведомого устройства снова исчезает, когда все открытые файловые дескрипторы закрываются ), в любом случае атомарно в одном и том же системном вызове.

• В OpenBSD это часть функциональности PTMGETуправления вводом-выводом на устройстве /dev/ptm. /devпо-прежнему является дисковым томом, и ядро ​​​​внутренне выдает соответствующие вызовы для создания там новых узлов устройств и сброса их владельцев и разрешений.
• Во FreeBSD это делается с помощью системного вызова posix_openpt(). /devвовсе не том диска. Это файловая система devfs. Он не содержит ни «мультиплексорного» устройства, ни файлов главного устройства, потому что posix_openpt()является прямым системным вызовом, а не обернутым ioctl()в дескрипторе открытого файла. Ведомые устройства появляются в файловой системе devfsв своем каталоге pts/.

Таким образом, ядро ​​гарантирует, что у них есть правильные разрешения и права собственности ab initio, и нет возможности, когда у них есть устаревшие разрешения. Таким образом, библиотечные функции grantpt()и unlockpt()по сути не являются -операциями, единственной оставшейся функциональностью которых является проверка переданного им файлового дескриптора и установка EINVAL, если он не является главной стороной псевдо-терминала -., потому что программы могут совершать глупые действия, например, передавать этим функциям не -псевдо--файловые дескрипторы терминала и ожидать, что они вернут ошибки.

Некоторое время в Linux псевдо-терминальные ведомые устройства были постоянными узлами устройств. Библиотека GNU C grantpt()не была системным вызовом. Скорее, он разветвил и выполнил установленную -вспомогательную программу UID с именем pt_chown, к большому разочарованию толпы не заданных -исполняемых файлов UID . Помните, что(grantpt()должен позволить непривилегированному пользователю изменить владельца и права доступа к специальному файлу устройства, которым он не обязательно владеет. )Так что окно возможности еще было,и Linux по-прежнему должен был поддерживать блокировку для unlockpt().

Ее «новая» devptsфайловая система (, где «новая» означает введенная несколько лет назад, теперь)почти позволяет делать то же самое, что и в FreeBSD с devfs, однако. Есть некоторые отличия.

• Есть еще устройство "мультиплексор".
  • В старой «новой» devptsсистеме это было ptmxустройство в другой devtmpfsфайловой системе, причем devptsфайловая система содержала только автоматически созданное/уничтоженное ведомое устройство. файлы. Обычно это была установка /dev/ptmxи сопутствующее крепление devptsна /dev/pts.
  • Но разработчики Linux хотели иметь несколько полностью независимых экземпляров файловой системы devptsдля контейнеров и т.п., и оказалось довольно сложно синхронизировать (правильные )два файловых систем, когда было многоdevtmpfsи devptsфайловых систем. Таким образом, в более новой "новой" devptsсистеме все устройства, мультиплексор и подчиненное устройство, находятся в одной файловой системе. В целях обратной совместимости по умолчанию новый узел ptmxбыл недоступен, если не был установлен новый параметр монтирования ptmxmode.
  • В еще более новом «новом» devptsфайл устройства ptmxв файловой системе devptsтеперь является первичным мультиплексором, а ptmxв devtmpfsлибо прокладка, предоставляемая ядром, которая пытается имитировать символическую ссылку, монтирование привязки или старую простую фактическую символическую ссылку на pts/ptmx.
• Ядро не всегда устанавливает права собственности и разрешения так, как должно grantpt(). Установка неправильных параметров монтирования, либо gid, отличного от ttyGID, либо mode, отличного от 0620, вызывает резервное поведение в библиотеке GNU C. Чтобы по желанию свести grantpt()к операции «нет» -в библиотеке GNU C, ядро ​​должно не назначать группу процесса открытия (, т.е.должна быть явная настройка gid), назначенная группа должна быть группой tty, а modeвновь созданных ведомых устройств должно быть точно 0620.

Не включение /dev/pts/ptmxпо умолчанию и библиотека GNU C, не полностью сводящая grantpt()к отказу -операции, являются следствием того, что ядро ​​и библиотека C не поддерживаются в синхронном режиме. Каждому приходилось работать со старыми версиями другого. Linux по-прежнему должен был предоставлять более старый /dev/ptmx. Библиотеке GNU C по-прежнему приходится возвращаться к работе pt_chown, если нет новой файловой системы devptsс правильными параметрами монтирования.

Таким образом, у unlockpt()по-прежнему существует окно возможностей для защиты от Linux, если devptsпараметры монтирования неверны и, следовательно, библиотеке GNU C приходится возвращаться к реальным действиям в grantpt().

Дополнительная литература

• https://unix.stackexchange.com/a/470853/5132
• Как лучше всего решить эту проблему с glibc?
• https://unix.stackexchange.com/a/214685/5132
• Documentation/filesystems/devpts.txt. ядро Линукс.
• Даниэль Берранж (2009 -05 -20 )./dev/ptsнеобходимо использовать флаг монтирования newinstance, чтобы избежать проблем безопасности с контейнерами. Ошибка RedHat #501718.
• Джонатан де Бойн Поллард (2018 ).open-controlling-tty. Направляющая ноша . Программное обеспечение.
• Джонатан де Бойн Поллард (2018 ).vc-get-tty. Направляющая ноша . Программное обеспечение.
• Джонатан де Бойн Поллард (2018 ).pty-get-tty. Направляющая ноша . Программное обеспечение.