Added "account required pam_mktemp.so" in 1.2.0-alt1

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

Тем более что при текущих настройках:

$ ls -ld /tmp/.private/raorn
drwxrwx--T  2 root raorn 4096 Jun  4 18:53 /tmp/.private/raorn

все sgid программы (например xscreensaver) пролетают мимо $TPMDIR как фанера над
парижем...

Доводов много, чтобы их здесь приводить.
Что касается требований к месту по разделам, то мы двигаемся в сторону
увеличения swap и помещения /tmp на tmpfs.
Что касается sgid-ных исполняемых объектов, то они могут чувствовать себя
спокойно начиная с glibc-2.2.5-alt6 (это ALT-specific).

(In reply to comment #4)
> Что касается sgid-ных исполняемых объектов, то они могут чувствовать себя
> спокойно начиная с glibc-2.2.5-alt6 (это ALT-specific).

Да, только что проверил на cscope.

Но всё равно, мне эта схема не очень нравится...  Как насчёт пользователей с
одной общей группой типа users?  Чем плох $HOME/tmp?  Может сделать таки
местонахождение $TMPDIR настраиваемым?

Разве оно перестало быть настраиваемым?
На общесистемном уровне pam_mktemp можно выключить так же просто, как и включить.
Каждый пользователь может переопределить любую переменную среды в своём
~/.bashrc или аналогичном файле.

/tmp оно на то и /tmp, что семантика у него другая, нежели у $HOME:

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

(In reply to comment #7)
> 4. Оно может быть на tmpfs ($HOME на tmpfs это просто волшебство)
А так?

wrar@wrars-comp ~ $ grep wrar /etc/fstab
usertmp   /home/wrar/tmp   tmpfs   size=1g 0 0

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

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

Это общий "недостаток" практически у всех файл-селекторов: если прав на чтение
каталога нет, пользователь не сможет пройти через него вверх или вниз.
Единственная идея, которая у меня есть, относится к файл-селекторам,
поддерживающим закладки (KDE, GNOME): в skel прописать закладку ко временному
каталогу. Тогда пользователь хотя бы сможет попасть во временный каталог снаружи.

А то что при входе в систему всегда создается /tmp/.private/$USER, так надо? И 
может быть вынести в конфиг какой "/tmp/.private"? 

(In reply to comment #11)
> А то что при входе в систему всегда создается /tmp/.private/$USER, так надо? И 
> может быть вынести в конфиг какой "/tmp/.private"? 
В этом и смысл "использования по умолчанию".
Не нравится - см. Comment #6.

(In reply to comment #6) 
> На общесистемном уровне pam_mktemp можно выключить так же просто, как и 
включить. 
> Каждый пользователь может переопределить любую переменную среды в своём 
> ~/.bashrc или аналогичном файле. 
 
На общесистемном уровне пакет не выносится, а каждый раз после обновления 
комментарить строчку в system-auth не хочется. Нет у меня столько swap чтоб 
использовать tmpfs, и нет у меня столько места в корне. Мне что теперь 
говорить каждому пользователю чтобы он изменил TMP/TMPDIR? Предлагаю в конфиг 
это добавить, например "account required pam_mktemp.so tempdir=/tmp/.private". 

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

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

2. Насчёт параметра для перемещения -- таки да, это интересная и полезная
функциональность, особенно если можно будет задавать и устанавливаемую
переменную (удобно для создания нескольких tmp под разные цели). Если напишете
грамотный патч, он наверняка будет принят.

(In reply to comment #10)
> Это общий "недостаток" практически у всех файл-селекторов:
Это _жуткие_ костыли, которые куда тяжелей выгоды от изменения.  Это говорю как
полюбляющий tmpfs и порой добирающийся до ~*/tmp на многопользовательских серверах.

Антон, надо изменить это умолчание в branch.  Оно абсолютно непрозрачное для
любого несвёрнутого набекрень мозгами пользователя :(

wrar, ldv: это _плохое_ умолчание.  Обоснование:

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

Неужели это так сложно понять?

2 mithraen: не гони волну, твои отсылки на FHS не более убедительны, чем тезис о
том, что временные данные пользователя -- это в первую очередь ДАННЫЕ
ПОЛЬЗОВАТЕЛЯ.  И дефолты должны создавать минимум проблем на ровном месте, если
тебе хочется удобного управления всеми TMPDIR в одном кусте -- ТЫ как
администратор это и настраивай, а не лепи всем без разбору :-/

-- 
Миша,
уже всерьёз злой

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

По совокупности лично мне очень нравится pam_mktemp плюс закладка на
/tmp/.private/ktirf

(In reply to comment #16)
> В-нулевых: Миш, остынь :) На эмоциях адекватного решения не найдётся.
Потому и привёл разбор по пунктам.  Мне из него табличку SWOT сделать?

> Лично мне, продвинутому пользователю настольной системы, нужно следующее:
Я тебе о том, что ПП имеет возможность осознанно улучшить настройки системы
относительно дефолтов.  А ОП (tm) -- при этом сгенерит в лучшем случае ещё и
кучу вопросов суппорту, знакомому или сообществу.

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

Я настоятельно попрошу всё обсуждение нетехнических вопросов вести за пределами
bugzilla.

(In reply to comment #18) 
> Я настоятельно попрошу всё обсуждение нетехнических вопросов вести за 
пределами 
> bugzilla. 
 
Почему, Дима? 
По-моему оно имеет прямое отношение к вопросу, и это лучше, чем вешать в 
коментарии ссылки на обсуждения, размазанные по всему .ru/.ua? 

home:~> sudo rpm -e pam0_mktemp            
Password:
error: removing these packages would break dependencies:
        pam_mktemp.so is needed by pam0-config-1.2.0-alt1

ась?

Пожалуйста, экономьте моё и ваше время.
Если у вас есть пожелания, формулируйте их отдельно от #6814.

В ходе обсуждения этой баги у ktirf@ прозвучала хорошая идея, но она не
относится к этому пакету. Мне она кажется очень здравой ... как результат: #8027 .

Created attachment 1133 [details]
/etc/control.d/facilities/pam_mktemp

Извините, что вмешиваюсь, но проблема "Обычных Пользователей(tm)" решается
одним файликом в /etc/control.d/facilities и галкой (или умолчательным
поведением) в инсталяторе.

Не знаю, есть ли противопоказания к применению control(8) на
/etc/pam.d/system-auth...

P.S. Названия состояний и описания обсуждабельны, я приехал только час назад
;-)

Я хотел бы добавить, что управлять умолчальным использованием pam_mktemp можно
при помощи самого факта установки или неустановки пакета pam_mktemp.

(In reply to comment #24)
> Я хотел бы добавить, что управлять умолчальным использованием pam_mktemp можно
> при помощи самого факта установки или неустановки пакета pam_mktemp.
Да? См. коммент 20.

По-моему, это не совсем нормальная ситуация.