Bug 8030 - [FR] control(8)lable /tmp/.private/ mode and usage
: [FR] control(8)lable /tmp/.private/ mode and usage
Status: CLOSED FIXED
: Sisyphus
(All bugs in Sisyphus/pam0_mktemp)
: unstable
: all Linux
: P2 enhancement
Assigned To:
:
: https://bugzilla.altlinux.org/show_bu...
:
:
: 12100 14167
  Show dependency tree
 
Reported: 2005-09-21 18:21 by
Modified: 2008-03-24 12:46 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2005-09-21 18:21:47
Would be nice to have /tmp/.private directory mode switchable between 0711
("server") and 0755 ("desktop") by means of control(8); being able to turn
pam_mktemp on/off similarly would be better yet.
------- Comment #1 From 2005-12-08 16:53:54 -------
Обоснование: на десктопе /tmp/.private/$USER непосредственно приводит к граблям
в сугубо пользовательских ситуациях вроде "клацнули по аттачу в почтовке,
открыли в (скажем) OOo, попытались сохранить из него куда-то -- ан кнопка
"вверх" ломается из-за невозможности прочитать /tmp/.private".

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

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

Иными словами, я настаиваю на откате такого дефолта, поскольку как дефолт он
неадекватен.  Те, кому на серверных инсталяциях по различным причинам удобнее
агрегировать временные файлы, пусть делают соответствующий control support или
локальные настройки.
------- Comment #2 From 2005-12-11 13:38:14 -------
Конкретнее, можешь описать ситуации когда 0755 на .private не спасёт?
Если таковых нет -- патч на pam_mktemp писать можно, нужно, и полезно (чтобы
опцию браз для прав на .private).

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

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

Any idea?
------- Comment #3 From 2006-12-07 20:23:44 -------
(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.

Пойми, я не против того, чтобы Диме, тебе и мне _на сервере_ было удобно зажать
весь мусор в одно ведро.  Просто дефолт это -- как из нас с тобой балерины.
------- Comment #4 From 2006-12-08 08:09:03 -------
От себя добавлю: после того, как семейство "открыло с сети" несколько 
видеофайлов, которые потом не удалились из /tmp (почему, не знаю, да это и не 
важно), в результате чего в /tmp, который на 300 мегабайтном /, просто 
закончилось место и "все сломалось". После чего я отказался от использования 
pam_mktemp вовсе, а /tmp после загрузки пробрасываю mount --bind'ом куда-нибудь 
в место, в котором "заведомо хватит места", например, в /var/tmp/.
------- Comment #5 From 2006-12-08 10:32:02 -------
Ну может лучше всё-таки /tmp делать отдельным разделом было? При чём тут
pam_mktemp?
------- Comment #6 From 2006-12-08 12:32:19 -------
При том, что делая неразумный дефолт в одном месте, следует хотя бы поддержать
его оригинальным дефолтом в другом.  (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 и
потом героическое их решение.

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

В подобных случаях удобно пользоваться cfdisk - в отличие от fdisk, он умеет
увеличивать размер extended (если, конечно, рядом с ним не лежит что-то
мешающее). Поэтому cfdisk нужно иметь в установщике рядом с fdisk, вне
зависимости от того, на чём будет сделана штатная разбивалка.
------- Comment #8 From 2006-12-18 14:33:55 -------
Мой вариант использования:

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

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

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

Соответственно всему этому разбивается диск - минимум для системы, максимум для
народа.
------- Comment #9 From 2006-12-18 15:22:14 -------
я не считаю pam_mktemp безусловным `the right thing'.
Поддержу предложение иметь на это дело control, off by default.
------- Comment #10 From 2006-12-18 15:27:47 -------
уточню, управлять хотелось бы фактом существования pam0_mktemp в связке,
а не правами ниже /tmp -- $TMPDIR, равная $HOME/tmp, для меня достаточна.
------- Comment #11 From 2007-03-18 02:59:46 -------
Предложенный вариант доступен здесь:
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 не делается.
------- Comment #12 From 2007-07-29 13:58:53 -------
2ldv: что будем с этим делать? Пока блокирует выход Desktop 4.0
------- Comment #13 From 2007-07-29 18:43:11 -------
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.
------- Comment #14 From 2007-10-09 12:13:50 -------
ack