---------------------------------------------------------------

> > * я не считаю pam_mktemp безусловным `the right thing'.
> >   Поддержу предложение иметь на это дело control, off by default.
> >   уточню, управлять хотелось бы фактом существования pam0_mktemp
> >   в связке,
> Я не против control.  Я не согласен с off by default.

Возможно ли сделать так, чтобы в серверном варианте дистрибутива
было как тебе видней, а в "общего назначения" -- off by default?

На серверах наиболее критичные проблемы или отсутствуют,
или снимаются при минимальном документировании на видном месте
"введения в ALT Server".

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

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

Дим, я ведь как умею -- тоже стараюсь помочь выпустить
такой дистрибутив, за который не будет стыдно.  Который
можно будет опять раздавать всем желающим, разворачивать
по всем проектам и писать вкусные анонсы на freshmeat,
lwn, distrowatch.  В котором будет интересно участвовать
и опытным вроде morozov@, и молодым вроде php-coder@.

---------------------------------------------------------------

On Sat, Mar 17, 2007 at 06:55:13PM +0300, Dmitry V. Levin wrote:
> > Разрешите присоединиться к этому утверждению. Я считаю, что
> > файлы пользователя (вне зависимости от их сорта и типа) не
> > должны лежать вне пределов его $HOME директории.
> Т.е. вы предлагаете каталоги /tmp и /var/tmp запретить совсем?

Это логически не следует.  Хотеть-то их запретить можно
(как и uid 0, и suid), да толку с того.

> > И мне совсем не улыбается, если они будут писаться в /tmp,
> Они будут записываться туда, куда вы скажете.

Так не хотелось бы сто раз "ёлочка, зажгись!".

On Sat, Mar 17, 2007 at 07:21:43PM +0300, Dmitry V. Levin wrote:
> > Executive summary:
> > + использовать tmpfs на swap универсальней, чем /tmp+swap;
> Я не совсем понимаю, что такое "универсальней".

В /tmp+swap не получается использовать место под /tmp для
свопа, если только не укладывать туда руками swapfiles.

А tmpfs позволяет использовать место и так, и так.
Вот и "более универсально".

> Я бы сказал иначе:
> + Хранить временные файлы на tmpfs эффективнее, поскольку tmpfs работает
>   заметно быстрее любой существующей файловой системы на диске.
> + Хранить временные файлы на tmpfs экономичнее с точки зрения расхода
>   дисковых ресурсов.

Ага.

> > + временные данные ДОЛЖНЫ жить в /tmp и никак иначе;
> Я бы переформулировал:
> + Временные данные располагаться в $TMPDIR/; всё остальное --
>   уже не совсем временное.

Ага.

Только решать временность -- владельцу этих данных.

> > + единый /tmp гораздо удобнее автоматически чистить;
> > + данное умолчание возможно изменить вручную индивидуально.
> + Данное умолчание возможно изменить вручную общесистемно.
> > - создаются отсутствовавшие до того проблемы пользования;
> Это субъективно; одни проблемы создаются, другие решаются.

Соображения по поводу _умолчаний_ высказал здесь:
https://bugzilla.altlinux.org/show_bug.cgi?id=6814#c15

> > - изменяется баланс расхода дискового пространства;
> Это является минусом только когда дисковое пространство не
> готово для изменения баланса.

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

> > - отсутствует аргументация изменения рабочей конфигурации;
> Это я не понимаю.

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

Хотя бы известить в sisyphus@ действительно было уместно.
Делать изменение идеально было бы вместе с ясно описанной
возможностью оставить всё как есть и ручкой вроде control.

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

Понимаешь, легко соглашаться с даже сложными выборами других
людей, когда результат работает.  В данном случае получается,
что выбор твой и mithraen@ оказывается важнее выбора тех,
кому достанется большинство негативных последствий -- даже
если им же в других задачах будет та же выгода от изменения.

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

> > - изменения возможно избежать только необновлением системы;
> Это не соответствует действительности.

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

Если бы это было не так, ты бы и сейчас использовал какой редхат.

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

Так начинать стоило с этого "улучшено".

> > - многократно нарушается принцип наименьшего удивления;
> Это очень субъективно.

Это summary; про свою субъективность написал выше.

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

Это мягкое изложение моего личного восприятия этого случая.

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

Ну "здесь" спрашивал sbolshakov@:
https://bugzilla.altlinux.org/show_bug.cgi?id=6814#c2

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

Мне тоже есть на что ещё потратить время.

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

Это очень субъективно.  В LDAP может быть одна-две на всех,
из жизненных примеров.

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

Спасибо; это решает "правовую" часть проблемы (но оставляет
"стораджевую").

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

Да, в случае официально рекомендуемого tmpfs для /tmp эта
проблема упрощается до "...при виде скрытого каталога в
общедоступном по записи".

А квоты на tmpfs работают?

> Кроме того, я согласовал с автором pam_mktemp добавление
> параметра, управляющего добавлением этого атрибута к
> /tmp/.private

Спасибо.

> > = 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 до сего времени, если честно.
> Ну если это одна из трёх наиболее тяжёлых, то я могу вздохнуть
> спокойно.

Да.  Предыдущие две давно в прошлом: принятие vsl@ и моя глупая
война с rider@ (в том числе и по части умолчаний) около 3.0.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/