40041 2021-05-12 15:51:29 +0300 lxc-attach leaks $TMP and $TMPDIR 2021-06-03 12:02:49 +0300 1 1 4 Development Sisyphus lxc-templates unstable x86_64 Linux REOPENED https://bugzilla.altlinux.org/show_bug.cgi?id=16024 P5 normal --- 1 s shaba dans ldv mike shaba sin qa-sisyphus oldest_to_newest 198404 0 s 2021-05-12 15:51:29 +0300 При установке alt внутри контейнера LXC директории /tmp/.private/root не существует, соответственно, все утилиты, предполагающие наличие каталога временных файлов, перестают работать. Возможно, это связано с тем, что root попадает в контейнер не через ssh, а через lxc-attach. --- Distribution: alt Release: p9 Architecture: amd64 Downloading the image index Downloading the rootfs Downloading the metadata The image cache is now ready Unpacking the rootfs --- You just created an Altlinux p9 x86_64 (20210512_01:17) container. host-15 ~ # lxc-start -n 1 host-15 ~ # lxc-ls -f NAME STATE AUTOSTART GROUPS IPV4 IPV6 UNPRIVILEGED 1 RUNNING 0 - 10.101.101.4 - false host-15 ~ # lxc-attach -n 1 [root@1 ~]# echo $TMP /tmp/.private/root [root@1 ~]# ls $TMP ls: невозможно получить доступ к '/tmp/.private/root': Нет такого файла или каталога [root@1 ~]# 198405 1 mike 2021-05-12 16:12:19 +0300 Возможно ещё, разъехались состояния по pam_mktemp -- попробуй в контейнере control pam_mktemp disabled 198406 2 vseleznv 2021-05-12 17:43:45 +0300 (In reply to Aceler from comment #0) > При установке alt внутри контейнера LXC директории /tmp/.private/root не > существует, соответственно, все утилиты, предполагающие наличие каталога > временных файлов, перестают работать. > > Возможно, это связано с тем, что root попадает в контейнер не через ssh, а > через lxc-attach. Да, если заходить через lxc-attach, то pam не отрабатывает. Могу предложить выполнять lxc-attach -n $CONT su, а лучше не использовать lxc-attach (использование вхождения в неймспейсы является одним из векторов атаки для побега злонамеренных процессов из контейнеров), а использовать ssh. Такое поведение by design, поэтому закрываю как NOTABUG. Можете открыть повторно, если возникнет предложение как можно исправить эту проблему. 198407 3 s 2021-05-12 18:05:38 +0300 В образе есть сервис systemd-tmpfiles-setup.service, который как раз предназначен для таких штук. Можно создать конфиг вида: $ cat /etc/tmpfiles.d/root D /tmp/.private/root 1700 root root - - 198408 4 vseleznv 2021-05-12 18:15:25 +0300 (In reply to Aceler from comment #3) > В образе есть сервис systemd-tmpfiles-setup.service, который как раз > предназначен для таких штук. > > Можно создать конфиг вида: > $ cat /etc/tmpfiles.d/root > D /tmp/.private/root 1700 root root - - Это будет тогда работать только для рута, но не для остальных пользователей. И это не исключает того, что всё остальное, что должен был сделать pam, сделано не будет. В любом случае, если так и делать, что уже не в пакете lxc. 198429 5 ldv 2021-05-13 12:04:24 +0300 (In reply to Aceler from comment #0) [...] > host-15 ~ # lxc-attach -n 1 > [root@1 ~]# echo $TMP > /tmp/.private/root > [root@1 ~]# ls $TMP > ls: невозможно получить доступ к '/tmp/.private/root': Нет такого файла или > каталога У меня вопрос, откуда взялось значение переменной $TMP (и $TMPDIR, что более важно)? Утекло из parent process через lxc-attach? > [root@1 ~]# 198433 6 s 2021-05-13 12:14:31 +0300 Да. host-15 ~ # echo $TMP /tmp/.private/root host-15 ~ # TMP=/tmp host-15 ~ # lxc-start -n 1 host-15 ~ # lxc-attach -n 1 [root@1 ~]# echo $TMP /tmp [root@1 ~]# 198435 7 ldv 2021-05-13 12:24:28 +0300 $ rpmquery --changelog coreutils ... * Sat Aug 30 2008 Dmitry V. Levin <ldv@altlinux> 6.12-alt1 ... - chroot: Purge TMP and TMPDIR variables from environment (closes: #16024). Предлагаю пропатчить lxc-attach аналогичным образом. 198436 8 s 2021-05-13 12:32:03 +0300 Возможно, это сломает поведение lxc-attach, потому что для очистки переменных там есть отдельный ключик --clear-env 198437 9 mike 2021-05-13 13:09:49 +0300 (Ответ для Aceler на комментарий #8) > Возможно, это сломает поведение lxc-attach Куда дальше наблюдаемого-то? > потому что для очистки переменных там есть отдельный ключик --clear-env А тут про две конкретные переменные разговор. 198448 10 s 2021-05-13 15:56:30 +0300 (Ответ для Michael Shigorin на комментарий #9) В теории, какой-нибудь juju может использовать lxc-attach, чтобы рулить контейнерами. И наверняка ожидает, что все переменные передаются в контейнер. Удаление пары переменных при сохранении остальных может что-то сломать. И чинить потом будет очень сложно. Да и в принципе, неконсистентненько. 198459 11 mike 2021-05-13 20:04:15 +0300 Ты не понял; подумай получше конкретно над своей же багой и тем, что именно это за переменные, кто и как их выставляет и что требуется для их работы. 198885 12 vseleznv 2021-06-03 12:02:49 +0300 (In reply to Aceler from comment #8) > Возможно, это сломает поведение lxc-attach, потому что для очистки > переменных там есть отдельный ключик --clear-env (In reply to Aceler from comment #10) > (Ответ для Michael Shigorin на комментарий #9) > > В теории, какой-нибудь juju может использовать lxc-attach, чтобы рулить > контейнерами. И наверняка ожидает, что все переменные передаются в контейнер. > > Удаление пары переменных при сохранении остальных может что-то сломать. И > чинить потом будет очень сложно. > > Да и в принципе, неконсистентненько. Апстрим предупреждал, что нужно быть готовым к поломке поведения в переменных окружения. Я на самом деле хочу поменять поведение по-умолчанию на clear env. Для прошлого поведения будет доступен ключит --keep-env. Вопрос: насколько сложно научить тот же juju использовать этот ключик?