[sisyphus] /tmp/.private/$USER vs $HOME/tmp как умолчание для TMPDIR

[Michael Shigorin]

On Sat, Mar 17, 2007 at 04:44:35AM +0300, Dmitry V. Levin wrote:
> > Мне вот только интересно, что с /tmp/.private при этом будет.
> > (не подумайте, что в восторге от _этого_, но в bugzilla меня
> > проигнорировали)
> Я не очень люблю вести обсуждения в bugzilla - этот инструмент для
> напоминания об ошибках не предназначен для обсуждения.
> Давайте лучше обсуждать здесь.

Хорошо.

Попробую пересказать доводы, приведённые в этих багах:
https://bugzilla.altlinux.org/show_bug.cgi?id=6814
https://bugzilla.altlinux.org/show_bug.cgi?id=8030
сторонниками и противниками использования pam_mktemp (TMPDIR
в /tmp/.private/$USER) по умолчанию (противников использования
/вообще/ не наблюдал):

Executive summary:

+ использовать tmpfs на swap универсальней, чем /tmp+swap;
+ временные данные ДОЛЖНЫ жить в /tmp и никак иначе;
+ единый /tmp гораздо удобнее автоматически чистить;
+ данное умолчание возможно изменить вручную индивидуально.

- создаются отсутствовавшие до того проблемы пользования;
- изменяется баланс расхода дискового пространства;
- отсутствует аргументация изменения рабочей конфигурации;
- изменения возможно избежать только необновлением системы;
- переконфигурирование требует заметной компетенции;
- многократно нарушается принцип наименьшего удивления;
- изменение производится в картельном порядке и предельно
  доступно изложенная аргументация удивившихся коллег
  игнорируется или получает ответ в духе "мы лучше знаем,
  что вам надо".

Осторожно, выдёргивание цитат лучше считать субъективным.

--- pro (mithraen, ldv):

* "Напоминаю про наше последнее обсуждение" [mithraen]

* Доводов много, чтобы их здесь приводить. [ldv]

* Что касается требований к месту по разделам, то мы двигаемся в
  сторону увеличения swap и помещения /tmp на tmpfs. [ldv]

* Разве оно перестало быть настраиваемым? [ldv]

* /tmp оно на то и /tmp, что семантика у него другая, нежели у $HOME:
  1. Данные из него могут быть удалены, если к ним не было
     обращений в течении некоторого времени
  2. Данные из него могут быть удалены при перезагрузке
  3. На нём может быть noexec
  4. Оно может быть на tmpfs ($HOME на tmpfs это просто волшебство)
  [mithraen]

* 1. /tmp в любой системе обязана быть, и выполнять именно те
  функции, которые положены по FHS (хранить временные данные,
  заведомо не имеющие смысла после перезагрузки). И делается это
  либо tmpfs, либо отдельным физическим разделом.

  Те кто не хотят делать так -- ССЗБ и пусть продолжают создавать
  себе геморрой самостоятельно.
  [mithraen]

* Если напишете грамотный патч, он наверняка будет принят. [mithraen]

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

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


--- contra (mike, sbolshakov и более мягко -- raorn и ktirf)

* нельзя ли в привести здесь доводы за такое решение ?
  с переездом TMPDIR некоторым образом изменились требования
  к распределению места по разделам, как минимум. [sbolshakov]

* /* проблемы для пользователей, которые не имеют соответствующей
     группы (до внесения специфических модификаций в glibc -- 
     и для SGID-программ, использующих TMPDIR) // mike */

  drwxrwx--T  2 root raorn 4096 Jun  4 18:53 /tmp/.private/raorn
  [...]
  Как насчёт пользователей с одной общей группой типа users?  [raorn]

* usertmp   /home/wrar/tmp   tmpfs   size=1g 0 0 [wrar]

* напоролся на то, что GUI'шный софт (точнее, файл-селектор в
  OOo) встал при попытке перейти из такого каталога в домашний
  "штатными средствами", бишь кнопкой "вверх" -- с жалобой "не
  могу прочитать каталог". [...] [mike]

* Это общий "недостаток" практически у всех файл-селекторов: если
  прав на чтение каталога нет, пользователь не сможет пройти через
  него вверх или вниз. [...] [ktirf]

* это _плохое_ умолчание.  Обоснование:
  - серверы требуют настройки
  - десктопы если и настраиваются, то редко квалифицированно
  - проблемы на серверах, которые это изменение решает, некритичны
  - проблемы на десктопах, которые оно создаёт -- критичны
  [mike]

* отсылки на FHS не более убедительны, чем тезис о том, что
  временные данные пользователя -- это в первую очередь ДАННЫЕ
  ПОЛЬЗОВАТЕЛЯ.  И дефолты должны создавать минимум проблем на
  ровном месте [...] [mike]

* Отвечать в тысячный раз в jabber, почту, телефон, что "это
  такие фирменные грабли, заточенные под некоторых продвинутых
  пользователей" -- не хочется совсем. [mike]

* error: removing these packages would break dependencies:
        pam_mktemp.so is needed by pam0-config-1.2.0-alt1 [mike]

* Не один администратор рефлекторно настрожится при виде
  неудаляемого скрытого каталога в общедоступном по записи /tmp.
  На сейчас все эти неприятности прибиты гвоздями к pam0_config. [mike]

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

* я не считаю pam_mktemp безусловным `the right thing'.
  Поддержу предложение иметь на это дело control, off by default.
  уточню, управлять хотелось бы фактом существования pam0_mktemp
  в связке, а не правами ниже /tmp -- $TMPDIR, равная $HOME/tmp,
  для меня достаточна. [sbolshakov]


--- pro et contra
? все sgid программы (например xscreensaver) пролетают мимо
  $TPMDIR как фанера над парижем... [raorn]
! Что касается sgid-ных исполняемых объектов, то они могут
  чувствовать себя спокойно начиная с glibc-2.2.5-alt6 (это
  ALT-specific). [ldv]

= Лично мне, продвинутому пользователю настольной системы, нужно следующее:
  1. Возможность разместить каталог (каталоги всех пользователей)
     на отдельной файловой системе (я люблю tmpfs, но здесь это не
     предполагается).
  2. Незаметность этого каталога в том смысле, что если уж он
     лежит у меня в ~, он должен начинаться на точку (обоснование:
     я не могу его удалить, потому что он нужен системе).
  3. Недоступность каталога одного пользователя другому пользователю.
  4. Быстрый и простой доступ к каталогу (/tmp/.private/username
     здесь явно проигрывает; в качестве ещё одного костыля могу
     предложить симлинк ~/tmp -> /tmp/.private/username).
  5. Нулевые затраты на maintenance этого каталога (stmpclean
     вполне справляется с этой задачей при условии его
     умолчательного правильного натравливания).
  По совокупности лично мне очень нравится pam_mktemp плюс
  закладка на /tmp/.private/ktirf [ktirf]

= Created an attachment (id=1133)
  /etc/control.d/facilities/pam_mktemp
  Извините, что вмешиваюсь, но проблема "Обычных
  Пользователей(tm)" решается одним файликом в
  /etc/control.d/facilities и галкой (или умолчательным
  поведением) в инсталяторе.  Не знаю, есть ли противопоказания к
  применению control(8) на /etc/pam.d/system-auth... [raorn]

Также в багрепортах были приведены несколько use cases, которые
демонстрировали вполне реальные проблемы с данным умолчанием
у достаточно компетентных людей, которые имеют возможность
хотя бы отдиагностировать проблему и обойти её.

Для меня это одна из трёх наиболее тяжёлых и неприятных ситуаций,
связанных с участием в разработке, развёртывании и поддержке
ALT Linux до сего времени, если честно.

> Что касается /tmp на swap'е по умолчанию в новых системах,
> то я не вижу ни одного реального минуса в этом подходе.

Мгм.

-- 
 ---- WBR, Michael Shigorin <mike на altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 189 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/sisyphus/attachments/20070317/b642fe6b/attachment-0003.bin>