Как вам предложение разработчиков Fedora об объединении каталогов для исполняемых файлов

В принципе при установки, обновлении и настройки системы опции надо менять!

mount -wo remount /
mount -wo remount /usr
mount -wo remount /usr/portage
mount -wo remount,exec /var

Иначе вы не сможете обновить и настроить систему ;)

Дурацкий опрос. Где вариант - «объединить /(s)bin и /usr/(s)bin»?

> что у криворуких идиотов она и не имеет выхода

единственная польза от общения с тобой

т.е. я идиот потому, что в общем случае дистрибутивы не имеют по умолчанию доступа к сети при базовой системе? Охерел?

И ответь на вопрос идиота, а как изменится ситуация если будет один каталог для исполняемых файлов? В этом случае должны возникнуть проблемы при восстановлении системы? Тем более что всяко можно хранить данные программ, пользователя на разных разделах и даже HDD. Не в ущерб базовой системе.

> т.е. я идиот потому, что в общем случае дистрибутивы не имеют по умолчанию доступа к сети при базовой системе?

Ты гонишь. Имеют.

> Считаю, нужно объединить /usr/{bin,sbin,games} в /usr/bin, а /bin и /sbin в /bin.

Ибо нет толку от логики «то root-only, а то для всех», хоть это и выглядит всё очень логично.

Ты дурачок. Нахрен мне в автодополнении весь хлам root'а?

> Ты дурачок. Нахрен мне в автодополнении весь хлам root'а?

потомучто часть программ от root — работает и в режиме пользователя ТОЖЕ.. но не полнофункционально, например в режиме read-only

зачем лишний раз набирать sudo и пароль, если такую операцию можно сделать без такогого?

>>....а если вы НЕ дадите доступ к какой-то из /sbin/* программ юзеру (например так часто делают на www-хостингах, плохая идея конешно), то с чего вдруг администратор думает что юзер себе в /home/the-usr/.local/sbin/ не накопирует нужного барахла своими силами?

/home, /tmp, /var (с /var/tmp) - у всех нормальных людей отдельные разделы с опцией noexec.

Всё где есть исполняемые файлы монтируется ro Всё что монтируется rw также монтируется с опцией noexec Эти правила написаны кровью! Также эти два правила оказали влияние на традиционную структуру каталогов UNIX и традиционную практику разбиение разделов при установки UNIX.

ну вот сразу видно что Вы — системный администратор :-D ... вам лижбы наделать глупых ограничений

noexec — вообще не добавляет какойлибо безопасности... она только гемороя добавляет при запуске бинарного файла из таковой`noexec`нутой директории

вот посмотри сюда — http://docs.python.org/library/ctypes.html ! любую функцию shared-object можно запустить из-под Python-скрипта... в том числе это касается и бинарных файлов (shared-object) которые лежат внутри noexec`нутой /home/the-usr/.local/

думаете там сложно добавить ключь -shared и -fPIC во время компиляции требуемой мне утилиты????

или будете и ./usr/bin/python тоже запрещать для запуска??? :-D :-D [тыг найдтся и куча других способов запустить *.so]

:-D

> т.е. я идиот потому, что в общем случае дистрибутивы не имеют по умолчанию доступа к сети при базовой системе?

кто криворукий идиот определяется следующим образом:

1. если твой дистрибутив не позволяет выйти в сеть по tcp/ip over ethernet при непримонтированном /usr, то криворукие идиоты — его разработчики

2. если же позволяет, но ты это не умеешь — то ты (т.к. громко тут рассказываешь про то, что это невозможно)

а как изменится ситуация если будет один каталог для исполняемых файлов? В этом случае должны возникнуть проблемы при восстановлении системы?

1. слияение /bin и /sbin скорее всего не повредит, но только делать это должен НЕ поттеринг

2. слияение /usr c остальным повредит

у меня обычно / /bin /sbin — это одна партиция, /boot /usr /tmp /home /var — 5 других

например, такой сценарий восстановления (можно сказать переустановка) для сильно убитой системы:

А. удаляем всю партицию /usr (правда, надо не забыть скопировать /usr/local)

В. нарезаем на ее месте 2 новые партиции — маленькая для нового / и большая для нового /usr

С. устанавливаем новую систему, не указывая ей старый раздел /var (т.е. новый /var лежит в корне) — чтобы инсталлятор не переписал и не затер чего лишнего в /var

и теперь у меня есть возможность дуалбута — загрузиться и в обрезанную старую систему и в новую систему

после этого:

Д. монтируем старый /var как /var в новой системе

дуалбут опять же сохраняем... вдруг найдутся баги

>..а теперь хм... чтоже предлагает нам Fedora(?), тыг она так и предлагает(!) — объеденить всё в одну директорию :-)

слияение /bin и /sbin скорее всего не повредит, но только делать это должен НЕ поттеринг

короче, см. мой пост выше

> зачем лишний раз набирать sudo и пароль, если такую операцию можно сделать без такогого?

Какие проблемы набрать /sbin/ifconfig ?

Пользователю всё это надо не часто, но хлам в автодополнении - это полная хрень.

>noexec — вообще не добавляет какойлибо безопасности... она только гемороя добавляет при запуске бинарного файла из таковой`noexec`нутой директории

В правильной hardened системе, в комплексе, добавляет безопасность!

99% эксплоитов режутся одной этой опцией!!! Да если безопасность основана на ней одной только то обойти можно.. но 99% детских эксплоитов этого делать не пытаются...

Совместно с другими средствами безопасности noexec существенно добавляет запас прочности!

Вся безопасность, можно сказать держится на ro для исполняемых областей и noexec для изменяемых! Это относится не только к дискам но и памяти!!! Если вы не придерживаетесь этого правила при создании системы - ваша система будет уязвима....

> Вся безопасность, можно сказать держится на ro для исполняемых областей и noexec для изменяемых

о! а это мне напомнило Гарвардскую архитектуру микроконтроллеров :-)

Ты ядро Hardened Линукса хоть раз собирал?

Что ставил на опции:

CONFIG_PAX_NOEXEC
CONFIG_PAX_PAGEEXEC
CONFIG_PAX_SEGMEXEC
CONFIG_PAX_MPROTECT
CONFIG_PAX_KERNEXEC

Не знаю о гарвардской архитектуре процов, но в современных процах правильных архитектур эти опции есть почти на уровни железа...

Открою тебе ещё одну тайну, в ядре вражеской NT от M$ они тоже реализованы!

> Ты ядро Hardened Линукса хоть раз собирал?

нет.. а зачем? :-)

ctypes — не работает в Hardened?

Если в dmesg будет что-то типа:

grsec: denied RWX mmap of <anonymous mapping> by /usr/bin/python2.7[python2.7:13757] uid/euid:1001/1001 gid/egid:0/0, parent /usr/bin/python2.7[noc-launcher.py:13750] uid/euid:0/0 gid/egid:0/0

то загрузись без /usr :) чтобы ни одна прога питон не заюзала, аккуратно примонтируй /usr и выполни под рутом:

paxctl -m /usr/bin/python2.7

Отключаем контроль памяти ядром только для питона.. Это меньшее зло чем CONFIG_PAX_MPROTECT = n

Я считаю что правильно спроектированная и написанная прога должна без проблем работать ( http://www.gentoo.org/proj/en/hardened/#doc_chap6 )

Из практики использования скажу что проблема в x86 особо там где криворукие пытаются использовать mmx* sse*... Также в большинства проприетарных проектах под линукс, и тех редких открытых где разработчикам говоришь что так писать плохо, присылаешь патчи, объясняешь, а они в ответ «анамнасрать»...