Напоминаю про наше последнее обсуждение об использовании pam_mktemp по-умолчанию.
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.
По-моему, это не совсем нормальная ситуация.
