Bug 8030 - [FR] control(8)lable /tmp/.private/ mode and usage
Summary: [FR] control(8)lable /tmp/.private/ mode and usage
Status: CLOSED FIXED
Alias: None
Product: Sisyphus
Classification: Development
Component: pam0_mktemp (show other bugs)
Version: unstable
Hardware: all Linux
: P2 enhancement
Assignee: Dmitry V. Levin
QA Contact: qa-sisyphus
URL: https://bugzilla.altlinux.org/show_bu...
Keywords:
Depends on:
Blocks: 12100 14167
  Show dependency tree
 
Reported: 2005-09-21 18:21 MSD by Michael Shigorin
Modified: 2008-03-24 12:46 MSK (History)
10 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Shigorin 2005-09-21 18:21:47 MSD
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 Michael Shigorin 2005-12-08 16:53:54 MSK
Обоснование: на десктопе /tmp/.private/$USER непосредственно приводит к граблям
в сугубо пользовательских ситуациях вроде "клацнули по аттачу в почтовке,
открыли в (скажем) OOo, попытались сохранить из него куда-то -- ан кнопка
"вверх" ломается из-за невозможности прочитать /tmp/.private".

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

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

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

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

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

Any idea?
Comment 3 Michael Shigorin 2006-12-07 20:23:44 MSK
(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 Alexey Morozov 2006-12-08 08:09:03 MSK
От себя добавлю: после того, как семейство "открыло с сети" несколько 
видеофайлов, которые потом не удалились из /tmp (почему, не знаю, да это и не 
важно), в результате чего в /tmp, который на 300 мегабайтном /, просто 
закончилось место и "все сломалось". После чего я отказался от использования 
pam_mktemp вовсе, а /tmp после загрузки пробрасываю mount --bind'ом куда-нибудь 
в место, в котором "заведомо хватит места", например, в /var/tmp/.
Comment 5 Alexey Rusakov 2006-12-08 10:32:02 MSK
Ну может лучше всё-таки /tmp делать отдельным разделом было? При чём тут pam_mktemp?
Comment 6 Michael Shigorin 2006-12-08 12:32:19 MSK
При том, что делая неразумный дефолт в одном месте, следует хотя бы поддержать
его оригинальным дефолтом в другом.  (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 Sergey Vlasov 2006-12-17 12:01:22 MSK
(In reply to comment #6)
> Как раз недавно проверялось -- при штатно стоящей на C:/D: winxp зарядить
> компакт вышло только на _два_ раздела (это чудо, винда в смысле, сделало
> extended аккурат под свой D:, оставив свободными два primary, а второй extended
> универсальный линуксовый fdisk не умеет).

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

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

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

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

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

Comment 13 Dmitry V. Levin 2007-07-29 18:43:11 MSD
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 Michael Shigorin 2007-10-09 12:13:50 MSD
ack