8030 2005-09-21 18:21:47 +0400 [FR] control(8)lable /tmp/.private/ mode and usage 2008-03-24 12:46:03 +0300 1 1 4 Development Sisyphus pam0_mktemp unstable all Linux CLOSED FIXED https://bugzilla.altlinux.org/show_bug.cgi?id=6814#c9 P2 enhancement --- 12100 14167 1 mike ldv abulava eostapets icesik kopilo4ka ktirf lav ldv mithraen placeholder vsu qa-sisyphus oldest_to_newest 30860 0 mike 2005-09-21 18:21:47 +0400 Would be nice to have /tmp/.private directory mode switchable between 0711 ("server") and 0755 ("desktop") by means of control(8); being able to turn pam_mktemp on/off similarly would be better yet. 33640 1 mike 2005-12-08 16:53:54 +0300 Обоснование: на десктопе /tmp/.private/$USER непосредственно приводит к граблям в сугубо пользовательских ситуациях вроде "клацнули по аттачу в почтовке, открыли в (скажем) OOo, попытались сохранить из него куда-то -- ан кнопка "вверх" ломается из-за невозможности прочитать /tmp/.private". Не один администратор рефлекторно настрожится при виде неудаляемого скрытого каталога в общедоступном по записи /tmp. На сейчас все эти неприятности прибиты гвоздями к pam0_config. Иными словами, я настаиваю на откате такого дефолта, поскольку как дефолт он неадекватен. Те, кому на серверных инсталяциях по различным причинам удобнее агрегировать временные файлы, пусть делают соответствующий control support или локальные настройки. 33711 2 mithraen 2005-12-11 13:38:14 +0300 Конкретнее, можешь описать ситуации когда 0755 на .private не спасёт? Если таковых нет -- патч на pam_mktemp писать можно, нужно, и полезно (чтобы опцию браз для прав на .private). А агрегировать tmp надо отнюдь нетолько на серверах. На рабочих станциях тоже весьма удобственно, ибо автоматически чистить можно штатными средствами. Временные файлы не должны лежать в $HOME. Это аксиома. Поэтому pam_mktemp "The Right Thing(tm)". Вопрос теперь в том, как сделать чтобы эта правильность не мешала usability. Any idea? 42826 3 mike 2006-12-07 20:23:44 +0300 (In reply to comment #2) <лирика> > А агрегировать tmp надо отнюдь нетолько на серверах. На рабочих станциях тоже > весьма удобственно, ибо автоматически чистить можно штатными средствами. Тебе точно в Индию надо съездить. Где в туалет 5* за тобой тащится мелкий такой индус. И вытирает тебе филейную часть, ибо не барское дело. И фиг от него отделаешься... Я выкину на помойку ОС, которая вздумает настаивать на том, "что мне удобственно". Потому что уже есть макось, которая просто работает, и винда, которая просто настаивает. Это технически. Давай сделаю, чтобы apache сразу садился на 127.0.0.1:8080 и Requires: nginx? Мне же так удобно, да и тебе, думаю, тоже? Или я буду невменяемым придурком, если стану навязывать свои предпочтения всем пользователям штатной сборки apache в ALT Linux таким образом? Это по части уважения к коллегам. </лирика> > Временные файлы не должны лежать в $HOME. Это аксиома. У меня другая: "временные пользовательские данные являются в первую очередь _пользовательскими данными_". Вопрос их размеров также может иметь кучу отличающихся по вариантам "/tmp vs /home" практических последствий: - разбивка диска - квоты - time mv > Поэтому pam_mktemp "The Right Thing(tm)". > Вопрос теперь в том, как сделать чтобы эта правильность не > мешала usability. Any idea? #define PRIVATE_PREFIX "/tmp/.private" видел? Половина проблем -- из-за прав и атрибутов, вешать их под control -- проще, чем /boot с /lib/modules. Но при этом всё равно остаётся вышеописанная часть вида /tmp vs /home. Пойми, я не против того, чтобы Диме, тебе и мне _на сервере_ было удобно зажать весь мусор в одно ведро. Просто дефолт это -- как из нас с тобой балерины. 42833 4 morozov 2006-12-08 08:09:03 +0300 От себя добавлю: после того, как семейство "открыло с сети" несколько видеофайлов, которые потом не удалились из /tmp (почему, не знаю, да это и не важно), в результате чего в /tmp, который на 300 мегабайтном /, просто закончилось место и "все сломалось". После чего я отказался от использования pam_mktemp вовсе, а /tmp после загрузки пробрасываю mount --bind'ом куда-нибудь в место, в котором "заведомо хватит места", например, в /var/tmp/. 42836 5 ktirf 2006-12-08 10:32:02 +0300 Ну может лучше всё-таки /tmp делать отдельным разделом было? При чём тут pam_mktemp? 42845 6 mike 2006-12-08 12:32:19 +0300 При том, что делая неразумный дефолт в одном месте, следует хотя бы поддержать его оригинальным дефолтом в другом. (btw, #define чуть выше видел? +снести pam_mktemp или оторвать, кроме как руками, сейчас никак) Compact 3.0.x при авторазбивке диска не делал ни отдельного /tmp, ни огромного свопа с /tmp на tmpfs. Мало того, я бы удивился, если бы это было так в "3.1" -- чем больше разделов свыше необходимых и достаточных / swap /home, тем больше шансов на всякие нюансы с другими ОС рядом. Как раз недавно проверялось -- при штатно стоящей на C:/D: winxp зарядить компакт вышло только на _два_ раздела (это чудо, винда в смысле, сделало extended аккурат под свой D:, оставив свободными два primary, а второй extended универсальный линуксовый fdisk не умеет). Своп пришлось положить файлом. И только не говори мне, что подобный недюжинный AI следует требовать от разбивки по умолчанию. Оно бы в простых случаях не глючило (#7605, #7874), и то хорошо. Мысли по поводу AI есть, и лисп тут очень при чём, но не всё и не сразу же. Есть более достойные первоочередные цели для оптимизации, как-то разнесение программ и данных по разделам и шпинделям и прочая автоматизация Partition mini-HOWTO и Multiple-Disk HOWTO, а не создание по умолчанию проблем с /tmp и потом героическое их решение. И это совсем отдельная не бага... 43247 7 vsu 2006-12-17 12:01:22 +0300 (In reply to comment #6) > Как раз недавно проверялось -- при штатно стоящей на C:/D: winxp зарядить > компакт вышло только на _два_ раздела (это чудо, винда в смысле, сделало > extended аккурат под свой D:, оставив свободными два primary, а второй extended > универсальный линуксовый fdisk не умеет). В подобных случаях удобно пользоваться cfdisk - в отличие от fdisk, он умеет увеличивать размер extended (если, конечно, рядом с ним не лежит что-то мешающее). Поэтому cfdisk нужно иметь в установщике рядом с fdisk, вне зависимости от того, на чём будет сделана штатная разбивалка. 43426 8 cetus 2006-12-18 14:33:55 +0300 Мой вариант использования: Я привык, что /tmp очень маленький и только для системных нужд. В нем все легко удаляется простым rm -rf от root, или даже при перезагрузке. Обнаружив, что rm -rf не работает, я теряюсь... Пользователю надо большой tmp - создать образ болванки, слазать в архив из midnight commander или другим файловым менеджером. Очень удобное место $HOME/tmp. Кроме того, поскольку это тоже tmp, по крону с помощью stmpclean все пользовательские tmp регулярно чистятся. Люди предупреждены, привыкли, и даже просят включать автоматическую чистку tmp и другого разного хлама. Соответственно всему этому разбивается диск - минимум для системы, максимум для народа. 43439 9 sbolshakov 2006-12-18 15:22:14 +0300 я не считаю pam_mktemp безусловным `the right thing'. Поддержу предложение иметь на это дело control, off by default. 43441 10 sbolshakov 2006-12-18 15:27:47 +0300 уточню, управлять хотелось бы фактом существования pam0_mktemp в связке, а не правами ниже /tmp -- $TMPDIR, равная $HOME/tmp, для меня достаточна. 46845 11 mike 2007-03-18 02:59:46 +0300 Предложенный вариант доступен здесь: http://git.altlinux.org/people/mike/packages/?p=pam-config.git;a=commit;h=6a1463ee73843fca44000e0a3a837c9c83b63999 http://git.altlinux.org/people/mike/packages/?p=pam_mktemp.git;a=commit;h=12b86dd85e2421d13fc8766b4fb31091dab81d6a http://git.altlinux.org/people/mike/packages/?p=pam_mktemp.git;a=commit;h=d7768f30f6d580e66727582459bb211eb0205ba2 По pam-config.spec: я убрал зависимость от pam_mktemp, при этом по умолчанию получается "отключено". Если её не отфильтровывать, будет по умолчанию "включено". Взаимодействие pam_mktemp.control и _обновления_ pam-config при наличии или отсутствии автоматизированных или ручных правок /etc/pam.d/system-auth не изучено; исходя из %config(noreplace) %_pamdir/system-auth* и того, что правится чужой конфиг, dump/restore не делается. 53268 12 aen 2007-07-29 13:58:53 +0400 2ldv: что будем с этим делать? Пока блокирует выход Desktop 4.0 53285 13 ldv 2007-07-29 18:43:11 +0400 As of pam0_mktemp-1.0.3-alt4/pam-config-control-1.4.2-alt1, # control pam_mktemp help enabled: Enable pam_mktemp support disabled: Disable pam_mktemp support $ stat -c %a /tmp/.private 755 That is, I consider the issue as resolved. 56312 14 mike 2007-10-09 12:13:50 +0400 ack