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