Возможно ещё, разъехались состояния по pam_mktemp -- попробуй в контейнере
control pam_mktemp disabled

(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. Можете открыть повторно, если возникнет предложение как можно исправить эту проблему.

В образе есть сервис systemd-tmpfiles-setup.service, который как раз предназначен для таких штук. 

Можно создать конфиг вида:
$ cat /etc/tmpfiles.d/root
D /tmp/.private/root 1700 root root - -

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

(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 ~]#

Да.

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 ~]#

$ 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 аналогичным образом.

Возможно, это сломает поведение lxc-attach, потому что для очистки переменных там есть отдельный ключик --clear-env

(Ответ для Aceler на комментарий #8)
> Возможно, это сломает поведение lxc-attach
Куда дальше наблюдаемого-то?

> потому что для очистки переменных там есть отдельный ключик --clear-env
А тут про две конкретные переменные разговор.

(Ответ для Michael Shigorin на комментарий #9)

В теории, какой-нибудь juju может использовать lxc-attach, чтобы рулить контейнерами. И наверняка ожидает, что все переменные передаются в контейнер.

Удаление пары переменных при сохранении остальных может что-то сломать. И чинить потом будет очень сложно.

Да и в принципе, неконсистентненько.

Ты не понял; подумай получше конкретно над своей же багой и тем, что именно это за переменные, кто и как их выставляет и что требуется для их работы.

(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 использовать этот ключик?