[sisyphus] /tmp/.private/$USER vs $HOME/tmp как умолчание для TMPDIR
Dmitry V. Levin
=?iso-8859-1?q?ldv_=CE=C1_altlinux=2Eorg?=
Сб Мар 17 19:21:43 MSK 2007
On Sat, Mar 17, 2007 at 04:41:38PM +0200, Michael Shigorin wrote:
> 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;
Я не совсем понимаю, что такое "универсальней". Я бы сказал иначе:
+ Хранить временные файлы на tmpfs эффективнее, поскольку tmpfs работает
заметно быстрее любой существующей файловой системы на диске.
+ Хранить временные файлы на tmpfs экономичнее с точки зрения расхода
дисковых ресурсов.
> + временные данные ДОЛЖНЫ жить в /tmp и никак иначе;
Я бы переформулировал:
+ Временные данные располагаться в $TMPDIR/; всё остальное --
уже не совсем временное.
> + единый /tmp гораздо удобнее автоматически чистить;
> + данное умолчание возможно изменить вручную индивидуально.
+ Данное умолчание возможно изменить вручную общесистемно.
> - создаются отсутствовавшие до того проблемы пользования;
Это субъективно; одни проблемы создаются, другие решаются.
> - изменяется баланс расхода дискового пространства;
Это является минусом только когда дисковое пространство не готово
для изменения баланса.
> - отсутствует аргументация изменения рабочей конфигурации;
Это я не понимаю.
> - изменения возможно избежать только необновлением системы;
Это не соответствует действительности.
> - переконфигурирование требует заметной компетенции;
Это субъективно и при необходимости может быть улучшено.
> - многократно нарушается принцип наименьшего удивления;
Это очень субъективно.
> - изменение производится в картельном порядке и предельно
> доступно изложенная аргументация удивившихся коллег
> игнорируется или получает ответ в духе "мы лучше знаем,
> что вам надо".
Это очень субъективно.
> * Доводов много, чтобы их здесь приводить. [ldv]
Ключевое слово "здесь".
> drwxrwx--T 2 root raorn 4096 Jun 4 18:53 /tmp/.private/raorn
> [...]
> Как насчёт пользователей с одной общей группой типа users? [raorn]
У каждого пользователя всё равно есть своя личная группа.
> * напоролся на то, что GUI'шный софт (точнее, файл-селектор в
> OOo) встал при попытке перейти из такого каталога в домашний
> "штатными средствами", бишь кнопкой "вверх" -- с жалобой "не
> могу прочитать каталог". [...] [mike]
>
> * Это общий "недостаток" практически у всех файл-селекторов: если
> прав на чтение каталога нет, пользователь не сможет пройти через
> него вверх или вниз. [...] [ktirf]
Я согласовал с автором pam_mktemp добавление параметра, управляющего
правами лоступа к каталогу /tmp/.private
> * Не один администратор рефлекторно настрожится при виде
> неудаляемого скрытого каталога в общедоступном по записи /tmp.
> На сейчас все эти неприятности прибиты гвоздями к pam0_config. [mike]
Неудаляемость имеет место быть не на всех файловых системах.
tmpfs не поддерживает эти атрибуты.
Кроме того, я согласовал с автором pam_mktemp добавление параметра,
управляющего добавлением этого атрибута к /tmp/.private
> * я не считаю pam_mktemp безусловным `the right thing'.
> Поддержу предложение иметь на это дело control, off by default.
> уточню, управлять хотелось бы фактом существования pam0_mktemp
> в связке,
Я не против control. Я не согласен с off by default.
> = Created an attachment (id=1133)
> /etc/control.d/facilities/pam_mktemp
> Извините, что вмешиваюсь, но проблема "Обычных
> Пользователей(tm)" решается одним файликом в
> /etc/control.d/facilities и галкой (или умолчательным
> поведением) в инсталяторе. Не знаю, есть ли противопоказания к
> применению control(8) на /etc/pam.d/system-auth... [raorn]
Судя по зависимостям пакета control, противопоказаний нет.
Другими словами, добавление control для system-auth и расширение
управляемости pam_mktemp должно снять возникшую напряжённость.
Так?
> Для меня это одна из трёх наиболее тяжёлых и неприятных ситуаций,
> связанных с участием в разработке, развёртывании и поддержке
> ALT Linux до сего времени, если честно.
Ну если это одна из трёх наиболее тяжёлых, то я могу вздохнуть спокойно.
--
ldv
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя : =?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/5ebfb3a5/attachment-0003.bin>
Подробная информация о списке рассылки Sisyphus