Bug 6814 - Использование по-умолчанию
Summary: Использование по-умолчанию
Status: CLOSED FIXED
Alias: None
Product: Sisyphus
Classification: Development
Component: pam0_mktemp (show other bugs)
Version: unstable
Hardware: all Linux
: P2 major
Assignee: Dmitry V. Levin
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks: 7079
  Show dependency tree
 
Reported: 2005-05-11 12:45 MSD by Denis Smirnov
Modified: 2012-03-16 13:57 MSK (History)
9 users (show)

See Also:


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

Note You need to log in before you can comment on or make changes to this bug.
Description Denis Smirnov 2005-05-11 12:45:09 MSD
Напоминаю про наше последнее обсуждение об использовании pam_mktemp по-умолчанию.
Comment 1 Dmitry V. Levin 2005-05-26 15:50:11 MSD
Added "account required pam_mktemp.so" in 1.2.0-alt1
Comment 2 Sergey Bolshakov 2005-06-04 19:09:32 MSD
нельзя ли в привести здесь доводы за такое решение ?
с переездом TMPDIR некоторым образом изменились требования
к распределению места по разделам, как минимум.
Comment 3 Sir Raorn 2005-06-04 19:17:30 MSD
Тем более что при текущих настройках:

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

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

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

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

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

Comment 8 Andrey Rahmatullin 2005-06-06 18:47:52 MSD
(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 Michael Shigorin 2005-08-12 21:33:54 MSD
Кстати, напоролся на то, что GUI'шный софт (точнее, файл-селектор в OOo) встал
при попытке перейти из такого каталога в домашний "штатными средствами", бишь
кнопкой "вверх" -- с жалобой "не могу прочитать каталог".

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

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

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

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

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

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

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

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

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

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

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

Отвечать в тысячный раз в jabber, почту, телефон, что "это такие фирменные
грабли, заточенные под некоторых продвинутых пользователей" -- не хочется совсем.
Comment 18 Dmitry V. Levin 2005-09-21 14:10:42 MSD
Я настоятельно попрошу всё обсуждение нетехнических вопросов вести за пределами
bugzilla.
Comment 19 Eugene V. Horohorin 2005-09-21 14:18:03 MSD
(In reply to comment #18) 
> Я настоятельно попрошу всё обсуждение нетехнических вопросов вести за 
пределами 
> bugzilla. 
 
Почему, Дима? 
По-моему оно имеет прямое отношение к вопросу, и это лучше, чем вешать в 
коментарии ссылки на обсуждения, размазанные по всему .ru/.ua? 
Comment 20 Michael Shigorin 2005-09-21 14:18:47 MSD
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 Dmitry V. Levin 2005-09-21 14:32:46 MSD
Пожалуйста, экономьте моё и ваше время.
Если у вас есть пожелания, формулируйте их отдельно от #6814.
Comment 22 Alexey Gladkov 2005-09-21 15:36:59 MSD
В ходе обсуждения этой баги у ktirf@ прозвучала хорошая идея, но она не
относится к этому пакету. Мне она кажется очень здравой ... как результат: #8027 .
Comment 23 Sir Raorn 2005-09-22 12:39:31 MSD
Created attachment 1133 [details]
/etc/control.d/facilities/pam_mktemp

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

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

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