On Sat, Mar 17, 2007 at 04:44:35AM +0300, Dmitry V. Levin wrote: > > Мне вот только интересно, что с /tmp/.private при этом будет. > > (не подумайте, что в восторге от _этого_, но в bugzilla меня > > проигнорировали) > Я не очень люблю вести обсуждения в bugzilla - этот инструмент для > напоминания об ошибках не предназначен для обсуждения. > Давайте лучше обсуждать здесь. Хорошо. Попробую пересказать доводы, приведённые в этих багах: https://bugzilla.altlinux.org/show_bug.cgi?id=6814 https://bugzilla.altlinux.org/show_bug.cgi?id=8030 сторонниками и противниками использования pam_mktemp (TMPDIR в /tmp/.private/$USER) по умолчанию (противников использования /вообще/ не наблюдал): Executive summary: + использовать tmpfs на swap универсальней, чем /tmp+swap; + временные данные ДОЛЖНЫ жить в /tmp и никак иначе; + единый /tmp гораздо удобнее автоматически чистить; + данное умолчание возможно изменить вручную индивидуально. - создаются отсутствовавшие до того проблемы пользования; - изменяется баланс расхода дискового пространства; - отсутствует аргументация изменения рабочей конфигурации; - изменения возможно избежать только необновлением системы; - переконфигурирование требует заметной компетенции; - многократно нарушается принцип наименьшего удивления; - изменение производится в картельном порядке и предельно доступно изложенная аргументация удивившихся коллег игнорируется или получает ответ в духе "мы лучше знаем, что вам надо". Осторожно, выдёргивание цитат лучше считать субъективным. --- pro (mithraen, ldv): * "Напоминаю про наше последнее обсуждение" [mithraen] * Доводов много, чтобы их здесь приводить. [ldv] * Что касается требований к месту по разделам, то мы двигаемся в сторону увеличения swap и помещения /tmp на tmpfs. [ldv] * Разве оно перестало быть настраиваемым? [ldv] * /tmp оно на то и /tmp, что семантика у него другая, нежели у $HOME: 1. Данные из него могут быть удалены, если к ним не было обращений в течении некоторого времени 2. Данные из него могут быть удалены при перезагрузке 3. На нём может быть noexec 4. Оно может быть на tmpfs ($HOME на tmpfs это просто волшебство) [mithraen] * 1. /tmp в любой системе обязана быть, и выполнять именно те функции, которые положены по FHS (хранить временные данные, заведомо не имеющие смысла после перезагрузки). И делается это либо tmpfs, либо отдельным физическим разделом. Те кто не хотят делать так -- ССЗБ и пусть продолжают создавать себе геморрой самостоятельно. [mithraen] * Если напишете грамотный патч, он наверняка будет принят. [mithraen] * А агрегировать tmp надо отнюдь нетолько на серверах. На рабочих станциях тоже весьма удобственно, ибо автоматически чистить можно штатными средствами. [mithraen] * Временные файлы не должны лежать в $HOME. Это аксиома. Поэтому pam_mktemp "The Right Thing(tm)". Вопрос теперь в том, как сделать чтобы эта правильность не мешала usability. [mithraen] --- contra (mike, sbolshakov и более мягко -- raorn и ktirf) * нельзя ли в привести здесь доводы за такое решение ? с переездом TMPDIR некоторым образом изменились требования к распределению места по разделам, как минимум. [sbolshakov] * /* проблемы для пользователей, которые не имеют соответствующей группы (до внесения специфических модификаций в glibc -- и для SGID-программ, использующих TMPDIR) // mike */ drwxrwx--T 2 root raorn 4096 Jun 4 18:53 /tmp/.private/raorn [...] Как насчёт пользователей с одной общей группой типа users? [raorn] * usertmp /home/wrar/tmp tmpfs size=1g 0 0 [wrar] * напоролся на то, что GUI'шный софт (точнее, файл-селектор в OOo) встал при попытке перейти из такого каталога в домашний "штатными средствами", бишь кнопкой "вверх" -- с жалобой "не могу прочитать каталог". [...] [mike] * Это общий "недостаток" практически у всех файл-селекторов: если прав на чтение каталога нет, пользователь не сможет пройти через него вверх или вниз. [...] [ktirf] * это _плохое_ умолчание. Обоснование: - серверы требуют настройки - десктопы если и настраиваются, то редко квалифицированно - проблемы на серверах, которые это изменение решает, некритичны - проблемы на десктопах, которые оно создаёт -- критичны [mike] * отсылки на FHS не более убедительны, чем тезис о том, что временные данные пользователя -- это в первую очередь ДАННЫЕ ПОЛЬЗОВАТЕЛЯ. И дефолты должны создавать минимум проблем на ровном месте [...] [mike] * Отвечать в тысячный раз в jabber, почту, телефон, что "это такие фирменные грабли, заточенные под некоторых продвинутых пользователей" -- не хочется совсем. [mike] * error: removing these packages would break dependencies: pam_mktemp.so is needed by pam0-config-1.2.0-alt1 [mike] * Не один администратор рефлекторно настрожится при виде неудаляемого скрытого каталога в общедоступном по записи /tmp. На сейчас все эти неприятности прибиты гвоздями к pam0_config. [mike] * Половина проблем -- из-за прав и атрибутов, вешать их под control -- проще, чем /boot с /lib/modules. Но при этом всё равно остаётся вышеописанная часть вида /tmp vs /home. [mike] * я не считаю pam_mktemp безусловным `the right thing'. Поддержу предложение иметь на это дело control, off by default. уточню, управлять хотелось бы фактом существования pam0_mktemp в связке, а не правами ниже /tmp -- $TMPDIR, равная $HOME/tmp, для меня достаточна. [sbolshakov] --- pro et contra ? все sgid программы (например xscreensaver) пролетают мимо $TPMDIR как фанера над парижем... [raorn] ! Что касается sgid-ных исполняемых объектов, то они могут чувствовать себя спокойно начиная с glibc-2.2.5-alt6 (это ALT-specific). [ldv] = Лично мне, продвинутому пользователю настольной системы, нужно следующее: 1. Возможность разместить каталог (каталоги всех пользователей) на отдельной файловой системе (я люблю tmpfs, но здесь это не предполагается). 2. Незаметность этого каталога в том смысле, что если уж он лежит у меня в ~, он должен начинаться на точку (обоснование: я не могу его удалить, потому что он нужен системе). 3. Недоступность каталога одного пользователя другому пользователю. 4. Быстрый и простой доступ к каталогу (/tmp/.private/username здесь явно проигрывает; в качестве ещё одного костыля могу предложить симлинк ~/tmp -> /tmp/.private/username). 5. Нулевые затраты на maintenance этого каталога (stmpclean вполне справляется с этой задачей при условии его умолчательного правильного натравливания). По совокупности лично мне очень нравится pam_mktemp плюс закладка на /tmp/.private/ktirf [ktirf] = Created an attachment (id=1133) /etc/control.d/facilities/pam_mktemp Извините, что вмешиваюсь, но проблема "Обычных Пользователей(tm)" решается одним файликом в /etc/control.d/facilities и галкой (или умолчательным поведением) в инсталяторе. Не знаю, есть ли противопоказания к применению control(8) на /etc/pam.d/system-auth... [raorn] Также в багрепортах были приведены несколько use cases, которые демонстрировали вполне реальные проблемы с данным умолчанием у достаточно компетентных людей, которые имеют возможность хотя бы отдиагностировать проблему и обойти её. Для меня это одна из трёх наиболее тяжёлых и неприятных ситуаций, связанных с участием в разработке, развёртывании и поддержке ALT Linux до сего времени, если честно. > Что касается /tmp на swap'е по умолчанию в новых системах, > то я не вижу ни одного реального минуса в этом подходе. Мгм. -- ---- WBR, Michael Shigorin ------ Linux.Kiev http://www.linux.kiev.ua/