39778 2021-03-10 12:41:56 +0300 posix_openpt непривилегированным пользователем 2023-08-25 15:11:28 +0300 1 1 4 Development Sisyphus setup unstable x86_64 Linux CLOSED FIXED P5 normal --- 1 slev legion glebfm ldv legion mogaba2009 placeholder rider vt qa-sisyphus oldest_to_newest 196830 0 slev 2021-03-10 12:41:56 +0300 При указанных ниже настройках по умолчанию `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? 196836 1 rider 2021-03-10 13:56:09 +0300 похоже на какое-то наше древнее 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 196837 2 slev 2021-03-10 14:01:55 +0300 Не указал, что это внутри контейнера(Docker): ``` # ls -la /dev/ptmx lrwxrwxrwx 1 root root 8 Mar 9 20:27 /dev/ptmx -> pts/ptmx ``` 196912 3 ldv 2021-03-11 18:41:50 +0300 В 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"}, 196913 4 ldv 2021-03-11 18:52:12 +0300 (In reply to Anton Farygin from comment #1) > похоже на какое-то наше древнее legacy. Дима наверняка знает больше. Эта строчка в нынешнем виде существует с 2006 года, т.е. задолго до того, как в ядре появились newinstance и ptmxmode. Кажется, ядерщики тут не вполне справились с обратной совместимостью. Алексей наверняка знает больше. :) 196915 5 legion 2021-03-11 19:04:55 +0300 (Ответ для Dmitry V. Levin на комментарий #4) > Эта строчка в нынешнем виде существует с 2006 года, т.е. задолго до того, > как в ядре появились newinstance и ptmxmode. > Кажется, ядерщики тут не вполне справились с обратной совместимостью. Eric W. Biederman рассказывал, что newinstance был большой ошибкой. > Алексей наверняка знает больше. :) Люди врут. Не знает. 196916 6 rider 2021-03-11 19:15:14 +0300 в итоге - поправите в setup ? 196917 7 ldv 2021-03-11 19:33:20 +0300 (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? 196918 8 legion 2021-03-11 19:43:36 +0300 (Ответ для Dmitry V. Levin на комментарий #7) > Ему не нравился интерфейс newinstance, он его убрал, там по сути теперь > всегда newinstance, но зачем он оставил DEVPTS_DEFAULT_PTMX_MODE 0000? Этого я не знаю. 196919 9 ldv 2021-03-11 19:48:47 +0300 На самом деле тут глючное взаимодействие: у /dev/ptmx правильные права, а у /dev/pts/ptmx неправильные. Если кому-то вздумается сделать вместо /dev/ptmx ссылку на pts/ptmx, как во времена newinstance, то и ptmxmode надо менять на 0666, как во времена newinstance. hasher эту ссылку делает со времён newinstance, ну так он и за ptmxmode следит. В обычной системе никто превращать /dev/ptmx в ссылку, по идее, не должен. Но вот существуют, оказывается, неконсистентные docker-контейнеры. 216746 10 mogaba2009 2022-11-01 08:49:43 +0300 Я столкнулся с похожей проблемой в стартерките для контейнеров: 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? Ничего при этом не сломается? 216747 11 ldv 2022-11-01 09:15:39 +0300 Повторю ещё раз: в ядре, начиная с коммита v4.7-rc2~3, newinstance стал неотключаемым. В этот же момент DEVPTS_DEFAULT_PTMX_MODE должен был поменяться с прежнего 0000 на 0666, но по невыясненной причине автор коммита Eric W. Biederman этого не сделал, поэтому весь userspace теперь вынужден добавлять ptmxmode=0666 и надеяться, что ядро содержит коммит v4.7-rc2~3. Применительно к пакету setup это означает, что придётся добавить ptmxmode=0666 и тем самым сломать поддержку более старых ядер. Наверное, для Сизифа это уже не проблема. 231900 12 repository-robot 2023-08-25 15:11:28 +0300 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)