Bug 6814 - Использование по-умолчанию
: Использование по-умолчанию
Status: CLOSED FIXED
: Sisyphus
(All bugs in Sisyphus/pam0_mktemp)
: unstable
: all Linux
: P2 major
Assigned To:
:
:
:
:
: 7079
  Show dependency tree
 
Reported: 2005-05-11 12:45 by
Modified: 2012-03-16 13:57 (History)


Attachments
/etc/control.d/facilities/pam_mktemp (547 bytes, text/plain)
2005-09-22 12:39, Sir Raorn
no flags Details


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2005-05-11 12:45:09
Напоминаю про наше последнее обсуждение об использовании pam_mktemp
по-умолчанию.
------- Comment #1 From 2005-05-26 15:50:11 -------
Added "account required pam_mktemp.so" in 1.2.0-alt1
------- Comment #2 From 2005-06-04 19:09:32 -------
нельзя ли в привести здесь доводы за такое решение ?
с переездом TMPDIR некоторым образом изменились требования
к распределению места по разделам, как минимум.
------- Comment #3 From 2005-06-04 19:17:30 -------
Тем более что при текущих настройках:

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

все sgid программы (например xscreensaver) пролетают мимо $TPMDIR как фанера над
парижем...
------- Comment #4 From 2005-06-04 21:30:57 -------
Доводов много, чтобы их здесь приводить.
Что касается требований к месту по разделам, то мы двигаемся в сторону
увеличения swap и помещения /tmp на tmpfs.
Что касается sgid-ных исполняемых объектов, то они могут чувствовать себя
спокойно начиная с glibc-2.2.5-alt6 (это ALT-specific).
------- Comment #5 From 2005-06-04 23:02:07 -------
(In reply to comment #4)
> Что касается sgid-ных исполняемых объектов, то они могут чувствовать себя
> спокойно начиная с glibc-2.2.5-alt6 (это ALT-specific).

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

Но всё равно, мне эта схема не очень нравится...  Как насчёт пользователей с
одной общей группой типа users?  Чем плох $HOME/tmp?  Может сделать таки
местонахождение $TMPDIR настраиваемым?
------- Comment #6 From 2005-06-04 23:22:05 -------
Разве оно перестало быть настраиваемым?
На общесистемном уровне pam_mktemp можно выключить так же просто, как и включить.
Каждый пользователь может переопределить любую переменную среды в своём
~/.bashrc или аналогичном файле.
------- Comment #7 From 2005-06-05 13:07:44 -------
/tmp оно на то и /tmp, что семантика у него другая, нежели у $HOME:

1. Данные из него могут быть удалены, если к ним не было обращений в течении
некоторого времени
2. Данные из него могут быть удалены при перезагрузке
3. На нём может быть noexec
4. Оно может быть на tmpfs ($HOME на tmpfs это просто волшебство)
------- Comment #8 From 2005-06-06 18:47:52 -------
(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
------- Comment #9 From 2005-08-12 21:33:54 -------
Кстати, напоролся на то, что GUI'шный софт (точнее, файл-селектор в OOo) встал
при попытке перейти из такого каталога в домашний "штатными средствами", бишь
кнопкой "вверх" -- с жалобой "не могу прочитать каталог".

Я-то путь вобью сразу полный нужный, да вот это типичная ситуация при "получили
почтой, ткнули мышом, почтовик закрыли, а файлик сохранить хочется" (и,
наверное, ряде других ситуаций).
------- Comment #10 From 2005-08-12 23:34:38 -------
Это общий "недостаток" практически у всех файл-селекторов: если прав на чтение
каталога нет, пользователь не сможет пройти через него вверх или вниз.
Единственная идея, которая у меня есть, относится к файл-селекторам,
поддерживающим закладки (KDE, GNOME): в skel прописать закладку ко временному
каталогу. Тогда пользователь хотя бы сможет попасть во временный каталог
снаружи.
------- Comment #11 From 2005-08-16 12:18:06 -------
А то что при входе в систему всегда создается /tmp/.private/$USER, так надо? И 
может быть вынести в конфиг какой "/tmp/.private"? 
------- Comment #12 From 2005-08-16 19:29:58 -------
(In reply to comment #11)
> А то что при входе в систему всегда создается /tmp/.private/$USER, так надо? И 
> может быть вынести в конфиг какой "/tmp/.private"? 
В этом и смысл "использования по умолчанию".
Не нравится - см. Comment #6.
------- Comment #13 From 2005-08-18 11:31:37 -------
(In reply to comment #6) 
> На общесистемном уровне pam_mktemp можно выключить так же просто, как и 
включить. 
> Каждый пользователь может переопределить любую переменную среды в своём 
> ~/.bashrc или аналогичном файле. 
 
На общесистемном уровне пакет не выносится, а каждый раз после обновления 
комментарить строчку в system-auth не хочется. Нет у меня столько swap чтоб 
использовать tmpfs, и нет у меня столько места в корне. Мне что теперь 
говорить каждому пользователю чтобы он изменил TMP/TMPDIR? Предлагаю в конфиг 
это добавить, например "account required pam_mktemp.so tempdir=/tmp/.private". 
------- Comment #14 From 2005-08-18 16:58:57 -------
1. /tmp в любой системе обязана быть, и выполнять именно те функции, которые
положены по FHS (хранить временные данные, заведомо не имеющие смысла после
перезагрузки). И делается это либо tmpfs, либо отдельным физическим разделом.

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

2. Насчёт параметра для перемещения -- таки да, это интересная и полезная
функциональность, особенно если можно будет задавать и устанавливаемую
переменную (удобно для создания нескольких tmp под разные цели). Если напишете
грамотный патч, он наверняка будет принят.
------- Comment #15 From 2005-09-21 12:03:06 -------
(In reply to comment #10)
> Это общий "недостаток" практически у всех файл-селекторов:
Это _жуткие_ костыли, которые куда тяжелей выгоды от изменения.  Это говорю как
полюбляющий tmpfs и порой добирающийся до ~*/tmp на многопользовательских серверах.

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

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

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

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

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

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

По совокупности лично мне очень нравится pam_mktemp плюс закладка на
/tmp/.private/ktirf
------- Comment #17 From 2005-09-21 13:50:35 -------
(In reply to comment #16)
> В-нулевых: Миш, остынь :) На эмоциях адекватного решения не найдётся.
Потому и привёл разбор по пунктам.  Мне из него табличку SWOT сделать?

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

Отвечать в тысячный раз в jabber, почту, телефон, что "это такие фирменные
грабли, заточенные под некоторых продвинутых пользователей" -- не хочется совсем.
------- Comment #18 From 2005-09-21 14:10:42 -------
Я настоятельно попрошу всё обсуждение нетехнических вопросов вести за пределами
bugzilla.
------- Comment #19 From 2005-09-21 14:18:03 -------
(In reply to comment #18) 
> Я настоятельно попрошу всё обсуждение нетехнических вопросов вести за 
пределами 
> bugzilla. 
 
Почему, Дима? 
По-моему оно имеет прямое отношение к вопросу, и это лучше, чем вешать в 
коментарии ссылки на обсуждения, размазанные по всему .ru/.ua? 
------- Comment #20 From 2005-09-21 14:18:47 -------
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

ась?
------- Comment #21 From 2005-09-21 14:32:46 -------
Пожалуйста, экономьте моё и ваше время.
Если у вас есть пожелания, формулируйте их отдельно от #6814.
------- Comment #22 From 2005-09-21 15:36:59 -------
В ходе обсуждения этой баги у ktirf@ прозвучала хорошая идея, но она не
относится к этому пакету. Мне она кажется очень здравой ... как результат:
#8027 .
------- Comment #23 From 2005-09-22 12:39:31 -------
Created an attachment (id=1133) [details]
/etc/control.d/facilities/pam_mktemp

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

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

P.S. Названия состояний и описания обсуждабельны, я приехал только час назад
;-)
------- Comment #24 From 2005-09-22 14:03:20 -------
Я хотел бы добавить, что управлять умолчальным использованием pam_mktemp можно
при помощи самого факта установки или неустановки пакета pam_mktemp.
------- Comment #25 From 2005-09-22 15:40:21 -------
(In reply to comment #24)
> Я хотел бы добавить, что управлять умолчальным использованием pam_mktemp можно
> при помощи самого факта установки или неустановки пакета pam_mktemp.
Да? См. коммент 20.
------- Comment #26 From 2005-09-22 16:29:06 -------
По-моему, это не совсем нормальная ситуация.