On Sat, Mar 17, 2007 at 10:31:38PM +0200, Michael Shigorin wrote:
> Возможно ли сделать так, чтобы в серверном варианте дистрибутива
> было как тебе видней, а в "общего назначения" -- off by default?

Я не претендую на абсолютное знание того, как лучше сделать по
умолчанию в том или ином продукте.  В этой ситуации я принимаю такое
решение, которое, на мой взгляд, принесёт большинству потенциальных
пользоваталей максимум пользы и минимум вреда.

Что касается серверного дистрибутива, то применение pam_mktemp там я
вижу совершенно оправданным.

Что касается дистрибутивов других профилей, то я хуже представляю себе
потенциальных пользователей этих продуктов.

> На системах общего назначения, в первую очередь десктопных --
> поверь на слово, ~/tmp by default лучше по многим причинам
> (скажи, где "здесь", расчертим-обсудим).

Ну раз зашёл разговор в этом списке, пусть будет в этом.
Только не в bugzilla.

> /* Это достаточно разумное умолчание общего плана, в отличие
>    от предположения высокой сознательности и компетентности
>    администратора и пользователей системы.  Один раз засунув 
>    впопыхах уникальный файлик в /tmp и вспомнив только когда 
>    он был прибит stmpclean'ом (M20), довольно хорошо помню
>    эмоции, которые в моём случае достались мне же, а в общем
>    -- стоит ожидать неконкретных жалоб на "теряющий данные 
>    альт" в публичных местах. */

Всё таки есть небольшая разница между $TMPDIR и $HOME/tmp:
Первый каталог предназначен для создания временных файлов с помощью
mkstemp(3) и ей подобными средствами; пользователь может и не знать о том,
когда эти файлы создаются и удаляются.
Второй каталог, видимо, предназначен для создания файлов пользователем
самостоятельно, при этом временность этих файлов определяет сам
пользователь.
Конечно, сисадмин и/или пользователь может сделать так, чтобы
$TMPDIR и $HOME/tmp совпадали (либо установив $TMPDIR равным $HOME/tmp,
либо сделав $HOME/tmp ссылкой на $TMPDIR).

> > > - изменяется баланс расхода дискового пространства;
> > Это является минусом только когда дисковое пространство не
> > готово для изменения баланса.
> 
> Проблема в том, что изменение разбивки обычно не является
> тривиальной задачей.  Особенно с учётом того, что "физический"
> /tmp живёт или на корне (худший и распространённый вариант),
> или в "быстром" начале диска.  Как и своп -- никак не в конце,
> где разделы таскать удобнее.

Я не призываю менять разбивку сразу.  Выключить pam_mktemp несложно.

> > > - изменения возможно избежать только необновлением системы;
> > Это не соответствует действительности.
> 
> В контексте _системы_ -- соответствует.  Аргументация вроде 
> того, что против каждого изменения можно, уже зная его, настелить
> соломы (сделать фейковый pam_mktemp.so, /etc/profile.d/tmpdir.sh
> -- как вот приходится, или иные контрмеры), непродуктивна.

Правильная системная ручка находится в system-auth.

> > > - переконфигурирование требует заметной компетенции;
> > Это субъективно и при необходимости может быть улучшено.
> 
> Так начинать стоило с этого "улучшено".

Невозможно начинать с улчшения того, что сперва не выглядит
нуждающимся в улучшении.

> > > * Доводов много, чтобы их здесь приводить. [ldv]
> > Ключевое слово "здесь".
> 
> Ну "здесь" спрашивал sbolshakov@:
> https://bugzilla.altlinux.org/show_bug.cgi?id=6814#c2

Мне не удобно вести обсуждения в bugzilla по чисто техническим причинам.
Вероятно, не мне одному.

> Приведи здесь, в sisyphus@.  Или скажи, где будет продуктивно.

Вроде бы привёл в предыдущем письме (мысленно собери все свои и мои +).

> > >   drwxrwx--T  2 root raorn 4096 Jun  4 18:53 /tmp/.private/raorn
> > >   [...]
> > >   Как насчёт пользователей с одной общей группой типа users?  [raorn]
> > У каждого пользователя всё равно есть своя личная группа.
> 
> Это очень субъективно.  В LDAP может быть одна-две на всех,
> из жизненных примеров.

Сисадмин, который использует LDAP таким образом, точно знает что он делает
и к каким последствиям это приведёт.

> > > * Это общий "недостаток" практически у всех файл-селекторов: если
> > >   прав на чтение каталога нет, пользователь не сможет пройти через
> > >   него вверх или вниз. [...] [ktirf]
> > Я согласовал с автором pam_mktemp добавление параметра,
> > управляющего правами лоступа к каталогу /tmp/.private
> 
> Спасибо; это решает "правовую" часть проблемы (но оставляет
> "стораджевую").

В конце концов, отключить монтирование /tmp - это закомментировать одну
строку в /etc/fstab.

Между прочим, при создании ovz-контейнера эта строка комментируется.

> > > * Не один администратор рефлекторно настрожится при виде
> > >   неудаляемого скрытого каталога в общедоступном по записи /tmp.
> > >   На сейчас все эти неприятности прибиты гвоздями к pam0_config. [mike]
> > Неудаляемость имеет место быть не на всех файловых системах.
> > tmpfs не поддерживает эти атрибуты.
> 
> Да, в случае официально рекомендуемого tmpfs для /tmp эта
> проблема упрощается до "...при виде скрытого каталога в
> общедоступном по записи".
> 
> А квоты на tmpfs работают?

Нет.  На сервере с недоверенными пользователями это может быть причиной
ограничения доступа к /tmp или отказа от использования tmpfs под /tmp.

> > Другими словами, добавление control для system-auth и расширение
> > управляемости pam_mktemp должно снять возникшую напряжённость.
> > Так?
> 
> В достаточной мере.  Вопрос разумности смены умолчания остаётся
> при этом открытым.

OK, послушаем, какие ещё будут мнения.


-- 
ldv