При указанных ниже настройках по умолчанию `posix_openpt` не выполняется с EACCES. ``` $ ls -la /dev/pts/ptmx c--------- 1 root root 5, 2 мар 8 14:28 /dev/pts/ptmx ``` То есть этот вызов будет работать только для CAP_DAC_OVERRIDE. ``` $ grep devpts /etc/fstab devpts /dev/pts devpts nosuid,noexec,gid=tty,mode=620 0 0 ``` По умолчанию опция монтирования devpts `ptmxmode=0000`. Это противоречит правилам udev(или наоборот): ``` $ grep -B 2 ptmx /lib/udev/rules.d/50-udev-default.rules ACTION!="add", GOTO="default_end" SUBSYSTEM=="tty", KERNEL=="ptmx", GROUP="tty", MODE="0666" ``` В этом случае побеждает fstab. При удалении devpts из fstab, ожидаемо, побеждает правило udev. Пример использования: для тестирования использую sshpass, который не может выполнить `posix_openpt` из-под непривилегированного пользователя. 1) не стоит ли привести в соответствие ptmxmode? 2) кто прав? является ли это политикой и какие проблемы могут быть с 666?
похоже на какое-то наше древнее legacy. Дима наверняка знает больше. К тому же: $ ls -al /dev/ptmx /dev/pts/ptmx crw-rw-rw- 1 root tty 5, 2 мар 10 13:55 /dev/ptmx c--------- 1 root root 5, 2 мар 3 17:32 /dev/pts/ptmx
Не указал, что это внутри контейнера(Docker): ``` # ls -la /dev/ptmx lrwxrwxrwx 1 root root 8 Mar 9 20:27 /dev/ptmx -> pts/ptmx ```
В hasher так: $ hsh-run --mount=/dev/pts -- ls -ld /dev/ptmx /dev/pts/ptmx lrwxrwxrwx 1 root root 8 Mar 11 15:30 /dev/ptmx -> pts/ptmx crw-rw-rw- 1 root 488 5, 2 Mar 11 15:30 /dev/pts/ptmx hasher-priv$ git grep /dev/pts ... hasher-priv/mount.c: {"devpts", "/dev/pts", "devpts", "ro,nosuid,noexec,gid=tty,mode=0620,ptmxmode=0666,newinstance"},
(In reply to Anton Farygin from comment #1) > похоже на какое-то наше древнее legacy. Дима наверняка знает больше. Эта строчка в нынешнем виде существует с 2006 года, т.е. задолго до того, как в ядре появились newinstance и ptmxmode. Кажется, ядерщики тут не вполне справились с обратной совместимостью. Алексей наверняка знает больше. :)
(Ответ для Dmitry V. Levin на комментарий #4) > Эта строчка в нынешнем виде существует с 2006 года, т.е. задолго до того, > как в ядре появились newinstance и ptmxmode. > Кажется, ядерщики тут не вполне справились с обратной совместимостью. Eric W. Biederman рассказывал, что newinstance был большой ошибкой. > Алексей наверняка знает больше. :) Люди врут. Не знает.
в итоге - поправите в setup ?
(In reply to Alexey Gladkov from comment #5) > (Ответ для Dmitry V. Levin на комментарий #4) > > Эта строчка в нынешнем виде существует с 2006 года, т.е. задолго до того, > > как в ядре появились newinstance и ptmxmode. > > Кажется, ядерщики тут не вполне справились с обратной совместимостью. > > Eric W. Biederman рассказывал, что newinstance был большой ошибкой. Ему не нравился интерфейс newinstance, он его убрал, там по сути теперь всегда newinstance, но зачем он оставил DEVPTS_DEFAULT_PTMX_MODE 0000?
(Ответ для Dmitry V. Levin на комментарий #7) > Ему не нравился интерфейс newinstance, он его убрал, там по сути теперь > всегда newinstance, но зачем он оставил DEVPTS_DEFAULT_PTMX_MODE 0000? Этого я не знаю.
На самом деле тут глючное взаимодействие: у /dev/ptmx правильные права, а у /dev/pts/ptmx неправильные. Если кому-то вздумается сделать вместо /dev/ptmx ссылку на pts/ptmx, как во времена newinstance, то и ptmxmode надо менять на 0666, как во времена newinstance. hasher эту ссылку делает со времён newinstance, ну так он и за ptmxmode следит. В обычной системе никто превращать /dev/ptmx в ссылку, по идее, не должен. Но вот существуют, оказывается, неконсистентные docker-контейнеры.
Я столкнулся с похожей проблемой в стартерките для контейнеров: https://www.altlinux.org/Starterkits/Download#%D0%9C%D0%B8%D0%BD%D0%B8%D0%BC%D0%B0%D0%BB%D1%8C%D0%BD%D1%8B%D0%B5_rootfs_%D0%B4%D0%BB%D1%8F_%D0%BA%D0%BE%D0%BD%D1%82%D0%B5%D0%B9%D0%BD%D0%B5%D1%80%D0%BE%D0%B2 Из-за того, что /dev/ptmx создается с правами 000, пользовательские процессы не могут создавать терминалы в devpts: $ mc Cannot open master and slave sides of pty: Нет такого файла или каталога (2) Я правильно понимаю, что можно просто закомментировать строку в /etc/fstab: devpts /dev/pts devpts nosuid,noexec,gid=tty,mode=620 0 0 - и сработает правило udev, где ptmxmode=0666? Ничего при этом не сломается?
Повторю ещё раз: в ядре, начиная с коммита v4.7-rc2~3, newinstance стал неотключаемым. В этот же момент DEVPTS_DEFAULT_PTMX_MODE должен был поменяться с прежнего 0000 на 0666, но по невыясненной причине автор коммита Eric W. Biederman этого не сделал, поэтому весь userspace теперь вынужден добавлять ptmxmode=0666 и надеяться, что ядро содержит коммит v4.7-rc2~3. Применительно к пакету setup это означает, что придётся добавить ptmxmode=0666 и тем самым сломать поддержку более старых ядер. Наверное, для Сизифа это уже не проблема.
setup-2.2.18-alt1 -> sisyphus: Fri Aug 25 2023 Alexey Gladkov <legion@altlinux.ru> 2.2.18-alt1 - /etc/services: update services (ALT#41676, ALT#47001) - /etc/protocols: Remove dups for 50 and 51 ports (ALT#35474) - /etc/fstab: Add ptmxmode=0666 for devpts (ALT#39778)
