Обоснование: на десктопе /tmp/.private/$USER непосредственно приводит к граблям
в сугубо пользовательских ситуациях вроде "клацнули по аттачу в почтовке,
открыли в (скажем) OOo, попытались сохранить из него куда-то -- ан кнопка
"вверх" ломается из-за невозможности прочитать /tmp/.private".

Не один администратор рефлекторно настрожится при виде неудаляемого скрытого
каталога в общедоступном по записи /tmp.

На сейчас все эти неприятности прибиты гвоздями к pam0_config.

Иными словами, я настаиваю на откате такого дефолта, поскольку как дефолт он
неадекватен.  Те, кому на серверных инсталяциях по различным причинам удобнее
агрегировать временные файлы, пусть делают соответствующий control support или
локальные настройки.

Конкретнее, можешь описать ситуации когда 0755 на .private не спасёт?
Если таковых нет -- патч на pam_mktemp писать можно, нужно, и полезно (чтобы
опцию браз для прав на .private).

А агрегировать tmp надо отнюдь нетолько на серверах. На рабочих станциях тоже
весьма удобственно, ибо автоматически чистить можно штатными средствами.

Временные файлы не должны лежать в $HOME. Это аксиома. Поэтому pam_mktemp "The
Right Thing(tm)". Вопрос теперь в том, как сделать чтобы эта правильность не
мешала usability.

Any idea?

(In reply to comment #2)
<лирика>
> А агрегировать tmp надо отнюдь нетолько на серверах. На рабочих станциях тоже
> весьма удобственно, ибо автоматически чистить можно штатными средствами.
Тебе точно в Индию надо съездить.  Где в туалет 5* за тобой тащится мелкий такой
индус.  И вытирает тебе филейную часть, ибо не барское дело.  И фиг от него
отделаешься...

Я выкину на помойку ОС, которая вздумает настаивать на том, "что мне
удобственно".  Потому что уже есть макось, которая просто работает, и винда,
которая просто настаивает.  Это технически.

Давай сделаю, чтобы apache сразу садился на 127.0.0.1:8080 и Requires: nginx? 
Мне же так удобно, да и тебе, думаю, тоже?  Или я буду невменяемым придурком,
если стану навязывать свои предпочтения всем пользователям штатной сборки apache
в ALT Linux таким образом?  Это по части уважения к коллегам.
</лирика>

> Временные файлы не должны лежать в $HOME. Это аксиома.
У меня другая: "временные пользовательские данные являются в первую очередь
_пользовательскими данными_".  Вопрос их размеров также может иметь кучу
отличающихся по вариантам "/tmp vs /home" практических последствий:
- разбивка диска
- квоты
- time mv

> Поэтому pam_mktemp "The Right Thing(tm)".
> Вопрос теперь в том, как сделать чтобы эта правильность не
> мешала usability. Any idea?
#define PRIVATE_PREFIX "/tmp/.private"
видел?

Половина проблем -- из-за прав и атрибутов, вешать их под control -- проще, чем
/boot с /lib/modules.  Но при этом всё равно остаётся вышеописанная часть вида
/tmp vs /home.

Пойми, я не против того, чтобы Диме, тебе и мне _на сервере_ было удобно зажать
весь мусор в одно ведро.  Просто дефолт это -- как из нас с тобой балерины.

От себя добавлю: после того, как семейство "открыло с сети" несколько 
видеофайлов, которые потом не удалились из /tmp (почему, не знаю, да это и не 
важно), в результате чего в /tmp, который на 300 мегабайтном /, просто 
закончилось место и "все сломалось". После чего я отказался от использования 
pam_mktemp вовсе, а /tmp после загрузки пробрасываю mount --bind'ом куда-нибудь 
в место, в котором "заведомо хватит места", например, в /var/tmp/.

Ну может лучше всё-таки /tmp делать отдельным разделом было? При чём тут pam_mktemp?

При том, что делая неразумный дефолт в одном месте, следует хотя бы поддержать
его оригинальным дефолтом в другом.  (btw, #define чуть выше видел?  +снести
pam_mktemp или оторвать, кроме как руками, сейчас никак)

Compact 3.0.x при авторазбивке диска не делал ни отдельного /tmp, ни огромного
свопа с /tmp на tmpfs.  Мало того, я бы удивился, если бы это было так в "3.1"
-- чем больше разделов свыше необходимых и достаточных / swap /home, тем больше
шансов на всякие нюансы с другими ОС рядом.

Как раз недавно проверялось -- при штатно стоящей на C:/D: winxp зарядить
компакт вышло только на _два_ раздела (это чудо, винда в смысле, сделало
extended аккурат под свой D:, оставив свободными два primary, а второй extended
универсальный линуксовый fdisk не умеет).  Своп пришлось положить файлом.

И только не говори мне, что подобный недюжинный AI следует требовать от разбивки
по умолчанию.  Оно бы в простых случаях не глючило (#7605, #7874), и то хорошо.

Мысли по поводу AI есть, и лисп тут очень при чём, но не всё и не сразу же. 
Есть более достойные первоочередные цели для оптимизации, как-то разнесение
программ и данных по разделам и шпинделям и прочая автоматизация Partition
mini-HOWTO и Multiple-Disk HOWTO, а не создание по умолчанию проблем с /tmp и
потом героическое их решение.

И это совсем отдельная не бага...

(In reply to comment #6)
> Как раз недавно проверялось -- при штатно стоящей на C:/D: winxp зарядить
> компакт вышло только на _два_ раздела (это чудо, винда в смысле, сделало
> extended аккурат под свой D:, оставив свободными два primary, а второй extended
> универсальный линуксовый fdisk не умеет).

В подобных случаях удобно пользоваться cfdisk - в отличие от fdisk, он умеет
увеличивать размер extended (если, конечно, рядом с ним не лежит что-то
мешающее). Поэтому cfdisk нужно иметь в установщике рядом с fdisk, вне
зависимости от того, на чём будет сделана штатная разбивалка.

Мой вариант использования:

Я привык, что /tmp очень маленький и только для системных нужд.
В нем все легко удаляется простым rm -rf от root, или даже при перезагрузке.
Обнаружив, что rm -rf не работает, я теряюсь...

Пользователю надо большой tmp - создать образ болванки, слазать в архив из
midnight commander или другим файловым менеджером. Очень удобное место $HOME/tmp.

Кроме того, поскольку это тоже tmp, по крону с помощью stmpclean все
пользовательские tmp регулярно чистятся. Люди предупреждены, привыкли, и даже
просят включать автоматическую чистку tmp и другого разного хлама.

Соответственно всему этому разбивается диск - минимум для системы, максимум для
народа.

я не считаю pam_mktemp безусловным `the right thing'.
Поддержу предложение иметь на это дело control, off by default.

уточню, управлять хотелось бы фактом существования pam0_mktemp в связке,
а не правами ниже /tmp -- $TMPDIR, равная $HOME/tmp, для меня достаточна.

Предложенный вариант доступен здесь:
http://git.altlinux.org/people/mike/packages/?p=pam-config.git;a=commit;h=6a1463ee73843fca44000e0a3a837c9c83b63999
http://git.altlinux.org/people/mike/packages/?p=pam_mktemp.git;a=commit;h=12b86dd85e2421d13fc8766b4fb31091dab81d6a
http://git.altlinux.org/people/mike/packages/?p=pam_mktemp.git;a=commit;h=d7768f30f6d580e66727582459bb211eb0205ba2
По pam-config.spec: я убрал зависимость от pam_mktemp, при этом по умолчанию
получается "отключено".  Если её не отфильтровывать, будет по умолчанию "включено".

Взаимодействие pam_mktemp.control и _обновления_ pam-config при наличии или
отсутствии автоматизированных или ручных правок /etc/pam.d/system-auth не
изучено; исходя из %config(noreplace) %_pamdir/system-auth* и того, что правится
чужой конфиг, dump/restore не делается.

2ldv: что будем с этим делать? Пока блокирует выход Desktop 4.0

As of pam0_mktemp-1.0.3-alt4/pam-config-control-1.4.2-alt1,

# control pam_mktemp help
enabled: Enable pam_mktemp support
disabled: Disable pam_mktemp support
$ stat -c %a /tmp/.private 
755

That is, I consider the issue as resolved.

ack