Bug 39778

Summary:	posix_openpt непривилегированным пользователем
Product:	Sisyphus	Reporter:	Stanislav Levin <slev>
Component:	setup	Assignee:	Alexey Gladkov <legion>
Status:	CLOSED FIXED	QA Contact:	qa-sisyphus
Severity:	normal
Priority:	P5	CC:	glebfm, ldv, legion, mogaba, placeholder, rider
Version:	unstable
Hardware:	x86_64
OS:	Linux

Description Stanislav Levin 2021-03-10 12:41:56 MSK

При указанных ниже настройках по умолчанию `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?

Comment 1 Anton Farygin 2021-03-10 13:56:09 MSK

похоже на какое-то наше древнее 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

Comment 2 Stanislav Levin 2021-03-10 14:01:55 MSK

Не указал, что это внутри контейнера(Docker):
```
# ls -la /dev/ptmx
lrwxrwxrwx 1 root root 8 Mar  9 20:27 /dev/ptmx -> pts/ptmx
```

Comment 3 Dmitry V. Levin 2021-03-11 18:41:50 MSK

В 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"},

Comment 4 Dmitry V. Levin 2021-03-11 18:52:12 MSK

(In reply to Anton Farygin from comment #1)
> похоже на какое-то наше древнее legacy. Дима наверняка знает больше.

Эта строчка в нынешнем виде существует с 2006 года, т.е. задолго до того, как в ядре появились newinstance и ptmxmode.
Кажется, ядерщики тут не вполне справились с обратной совместимостью.
Алексей наверняка знает больше. :)

Comment 5 Alexey Gladkov 2021-03-11 19:04:55 MSK

(Ответ для Dmitry V. Levin на комментарий #4)
> Эта строчка в нынешнем виде существует с 2006 года, т.е. задолго до того,
> как в ядре появились newinstance и ptmxmode.
> Кажется, ядерщики тут не вполне справились с обратной совместимостью.

Eric W. Biederman рассказывал, что newinstance был большой ошибкой.

> Алексей наверняка знает больше. :)

Люди врут. Не знает.

Comment 6 Anton Farygin 2021-03-11 19:15:14 MSK

в итоге - поправите в setup ?

Comment 7 Dmitry V. Levin 2021-03-11 19:33:20 MSK

(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?

Comment 8 Alexey Gladkov 2021-03-11 19:43:36 MSK

(Ответ для Dmitry V. Levin на комментарий #7)
> Ему не нравился интерфейс newinstance, он его убрал, там по сути теперь
> всегда newinstance, но зачем он оставил DEVPTS_DEFAULT_PTMX_MODE 0000?

Этого я не знаю.

Comment 9 Dmitry V. Levin 2021-03-11 19:48:47 MSK

На самом деле тут глючное взаимодействие: у /dev/ptmx правильные права, а у /dev/pts/ptmx неправильные.  Если кому-то вздумается сделать вместо /dev/ptmx ссылку на pts/ptmx, как во времена newinstance, то и ptmxmode надо менять на 0666, как во времена newinstance.  hasher эту ссылку делает со времён newinstance, ну так он и за ptmxmode следит.  В обычной системе никто превращать /dev/ptmx в ссылку, по идее, не должен.  Но вот существуют, оказывается, неконсистентные docker-контейнеры.

Comment 10 Vladimir Mokrozub 2022-11-01 08:49:43 MSK

Я столкнулся с похожей проблемой в стартерките для контейнеров:
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? Ничего при этом не сломается?

Comment 11 Dmitry V. Levin 2022-11-01 09:15:39 MSK

Повторю ещё раз: в ядре, начиная с коммита v4.7-rc2~3, newinstance стал неотключаемым.
В этот же момент DEVPTS_DEFAULT_PTMX_MODE должен был поменяться с прежнего 0000 на 0666, но по невыясненной причине автор коммита Eric W. Biederman этого не сделал, поэтому весь userspace теперь вынужден добавлять ptmxmode=0666 и надеяться, что ядро содержит коммит v4.7-rc2~3.

Применительно к пакету setup это означает, что придётся добавить ptmxmode=0666 и тем самым сломать поддержку более старых ядер.  Наверное, для Сизифа это уже не проблема.

Comment 12 Repository Robot 2023-08-25 15:11:28 MSK

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)