В связи с возможным объединением каталогов /bin и /sbin в один хотелось бы узнать почему кто-то против этого? Какие минусы вы в этом видите?
для начала, хотелось-бы выслушать ваши доводы ЗА такое объединение.
Леннарт Поттеринг в списке рассылки разработчиков предоставляет список преимуществ такого подхода:
ds: главный лемминг-проводник ведёт остальных леммингов в пропасть.
разделение на /bin и /sbin приводит к усложнению работы разработчиков, которые зачастую ошибаются с выбором каталога, либо бездумно помещают файлы в /usr/bin;
Если у нас настолько тупорылые разработчики, то почему-бы не свалить всю помойку на диск C: ?
первоначальное назначение каталога /sbin (размещение статически собранных файлов, на что указывает буква «s») давно неактуально;
man hier
/sbin Like /bin, this directory holds commands needed to boot the system, but
which are usually not executed by normal users.
выделенное слово хорошо видно?
разделение на /bin и /sbin не имеет отношения к безопасности (это был бы глупый принцип «security by obscurity»);
Леннарт -- лемминг.
Если вы тоже лемминг, дальше не читайте. Если вы умеете думать головой, прочтите:
$PATH имеет непосредственное отношение к безопасности. Однако, вовсе НЕ потому, что он "что-то скрывает". Это наглое ЛПП. На самом деле, $PATH уменьшает риск подмены, т.е. если юзер набрал ls, то он _ожидает_, что выполнится /bin/ls, а не как в маздае $PWD/ls. Разница существенная, ибо враг в принципе обычно имеет доступ к $PWD (это текущий каталог, и враг может например подсунуть архив, в котором лежит ЕГО ls), и враг може обмануть пользователя, попросив его выполнить его команду, которая на самом деле -- вредоносный код злоумышленника.
Существует класс потенциально опасных утилит, которыми можно загубить ВСЁ, и которые обычно всё равно не нужны пользователю. В качестве примера можно привести /sbin/mke2fs, которая в GNU/Linux эквивалентна FORMAT в MS-DOS-подобных ОС.
Если юзеру нужны такие программы (что бывает крайне редко), то юзеру следует набрать полный путь, дабы быть уверенным в том, что опасная команда сделает именно то, что он хочет. Например:
text
$ /sbin/fdisk -l
Диск /dev/sda: 8035 МБ, 8035237888 байт
162 heads, 28 sectors/track, 3459 cylinders, всего 15693824 секторов
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x4efc010b
Устр-во Загр Начало Конец Блоки Id Система
/dev/sda1 * 28 99791 49882 83 Linux
/dev/sda2 99792 15693823 7797016 83 Linux
Безусловно Леннарт об этом знает, и сознательно вводит в заблуждение остальных леммингов.
разделение на /bin и /sbin имеет значение только для переменной $PATH, однако усложнять доступ пользователей к некоторым инструментам - плохая затея; к тому же для этого есть более подходящие каталоги;
см. выше. Ну и демагогия детектед: НЕ ТОЛЬКО для $PATH это важно. Системные компоненты вообще полезно держать в отдельном ящике. Например у меня дома ножовка/молоток/паяльник лежат отдельно. Дети знают где (я от них ничего не скрываю), и знают, что лазать туда НЕЛЬЗЯ. И совсем не потому, что у них это не получается. Получится, если надо будет, а папы нет поблизости. Ну а обычные инструменты лежат в других ящиках, доступных без особых разрешений.
разделение на /bin и /sbin в любом случае бессмысленно уже пару версий Fedora, поскольку оба каталога включены в переменную $PATH для всех пользователей;
федоррапроблемы.
разделение приводит к усложнению, а мы должны стремиться к упрощению;
ящик со специальными инструментами -- тоже усложнение. Да и вообще -- идеал простоты: помойка. Мы должны стремится к помойке?
различные дистрибутивы размещают некоторые бинарные файлы в различных каталогах, что приводит к проблемам с переносимостью скриптов;
и это -- хорошо. Ибо вредоносные скрипты почти всегда не работают, а если даже работают, то не заражают другие системы. Ибо для запуска нужен живой админ, а он вирусы будет запускать лишь тогда, когда ему ЭТО действительно нужно.
разделение на /bin и /usr/bin в основном было сделано для этапа ранней загрузки системы - минимальный набор загрузочных файлов находится в /. Но это давно не работает, и соответствующая опция убрана из инсталлятора anaconda. Более того, размещение /usr на отдельной файловой системе вызывает проблемы при загрузе посредством systemd;
т.е. тут Леннарт сам признался, что он неосилятор, и не осилил сделать systemd, который работает везде? Простите, это система для systemd, или всё же наоборот?
разделение на минимальную систему в / и полную в /usr также стало бессмысленно благодаря initrd, а содержание двух уровней «минимальной загрузочной системы» - дурацкая затея;
Ложь. Рассчитана на тех леммингов, кто не понимает магии initrd.
существенно упростится установка «read-only» системы: так, libc и другие системные библиотеки будут доступны только на чтение, а /etc - на чтение и запись;
Ещё одна ложь. Чем /sbin/ тут мешает? Причём тут вообще это?
снятие снапшотов станет действительно атомарной операцией. В настоящее время btrfs требует 5 снимков - /lib, /lib64, /bin, /sbin и /usr вместо одного, что неудобно и может приводить к состояниям гонки;
ложь. Если свалить всё в одну кучу, то это ничего не изменит. Скорее наоборот. Проще сделать 5 непротиворечивых снимков, чем одну групповую фотографию. Это любой фотограф знает. На любой групповой фотке всегда кто-нибудь получится с закрытыми глазами (моргает), или просто с рожей, как у олигофрена.
существенно упростятся сетевая и контейнерная установки;
ложь. Просто ещё одна ложь.
сборочные скрипты упростятся: в частности, autoconf не знает о разделении на / и /usr, и для правильной работы с ними приходится прилагать специальные усилия;
autoconf И НЕ ДОЛЖЕН ЭТОГО ЗНАТЬ, дурья твоя бошка! Autoconf ставит ПО не туда, куда хочется Леннарту, а туда, куда хочет АДМИНИСТРАТОР. Если надо -- будет ставить в $HOME, и получится "портабельная программа".
эксперименты уже показали жизнеспособность предложенной схемы и отсутствие серьезных проблем;
В Windows 3.11 тоже не было никаких вирусов.
есть разработчик (Harald Hoyer), готовый выполнить необходимую работу.
В связи с возможным объединением каталогов /bin и /sbin в один хотелось бы узнать почему кто-то против этого? Какие минусы вы в этом видите?
Да никаких рациональных минусов никто не видит. Простое верещание людишек с одубевшим мозгом.
Я бы вообще сделал так: /bin - для низкоуровневых системных бинарников, /usr/bin - для остальных приложений, /usr/sh - для пользовательских скриптов (баш, питон, etc). А то развели 6 каталогов для исполняемых файлов, ума палата просто.
Возражения в части /bin и /usr/bin вполне понятны.
А по вопросу объединения /bin и /sbin навскидку из технических резонов только возможность ограничения доступа к содержимому последнего. Из нетехнических -- требование дополнительных телодвижений для доступа к потенциально опасным командам.
[quote="Vascom"]В связи с возможным объединением каталогов /bin и /sbin в один хотелось бы узнать почему кто-то против этого? Какие минусы вы в этом видите?
для начала, хотелось-бы выслушать ваши доводы ЗА такое объединение.
Леннарт Поттеринг в списке рассылки разработчиков предоставляет список преимуществ такого подхода:
ds: главный лемминг-проводник ведёт остальных леммингов в пропасть.
разделение на /bin и /sbin приводит к усложнению работы разработчиков, которые зачастую ошибаются с выбором каталога, либо бездумно помещают файлы в /usr/bin;
Если у нас настолько тупорылые разработчики, то почему-бы не свалить всю помойку на диск C: ?
первоначальное назначение каталога /sbin (размещение статически собранных файлов, на что указывает буква «s») давно неактуально;
man hier
/sbin Like /bin, this directory holds commands needed to boot the system, but
which are usually not executed by normal users.
выделенное слово хорошо видно?
разделение на /bin и /sbin не имеет отношения к безопасности (это был бы глупый принцип «security by obscurity»);
Леннарт -- лемминг.
Если вы тоже лемминг, дальше не читайте. Если вы умеете думать головой, прочтите:
$PATH имеет непосредственное отношение к безопасности. Однако, вовсе НЕ потому, что он "что-то скрывает". Это наглое ЛПП. На самом деле, $PATH уменьшает риск подмены, т.е. если юзер набрал ls, то он _ожидает_, что выполнится /bin/ls, а не как в маздае $PWD/ls. Разница существенная, ибо враг в принципе обычно имеет доступ к $PWD (это текущий каталог, и враг может например подсунуть архив, в котором лежит ЕГО ls), и враг може обмануть пользователя, попросив его выполнить его команду, которая на самом деле -- вредоносный код злоумышленника.
Существует класс потенциально опасных утилит, которыми можно загубить ВСЁ, и которые обычно всё равно не нужны пользователю. В качестве примера можно привести /sbin/mke2fs, которая в GNU/Linux эквивалентна FORMAT в MS-DOS-подобных ОС.
Если юзеру нужны такие программы (что бывает крайне редко), то юзеру следует набрать полный путь, дабы быть уверенным в том, что опасная команда сделает именно то, что он хочет. Например:
text
$ /sbin/fdisk -l
Диск /dev/sda: 8035 МБ, 8035237888 байт
162 heads, 28 sectors/track, 3459 cylinders, всего 15693824 секторов
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x4efc010b
Устр-во Загр Начало Конец Блоки Id Система
/dev/sda1 * 28 99791 49882 83 Linux
/dev/sda2 99792 15693823 7797016 83 Linux
Безусловно Леннарт об этом знает, и сознательно вводит в заблуждение остальных леммингов.
разделение на /bin и /sbin имеет значение только для переменной $PATH, однако усложнять доступ пользователей к некоторым инструментам - плохая затея; к тому же для этого есть более подходящие каталоги;
см. выше. Ну и демагогия детектед: НЕ ТОЛЬКО для $PATH это важно. Системные компоненты вообще полезно держать в отдельном ящике. Например у меня дома ножовка/молоток/паяльник лежат отдельно. Дети знают где (я от них ничего не скрываю), и знают, что лазать туда НЕЛЬЗЯ. И совсем не потому, что у них это не получается. Получится, если надо будет, а папы нет поблизости. Ну а обычные инструменты лежат в других ящиках, доступных без особых разрешений.
разделение на /bin и /sbin в любом случае бессмысленно уже пару версий Fedora, поскольку оба каталога включены в переменную $PATH для всех пользователей;
федоррапроблемы.
разделение приводит к усложнению, а мы должны стремиться к упрощению;
ящик со специальными инструментами -- тоже усложнение. Да и вообще -- идеал простоты: помойка. Мы должны стремится к помойке?
различные дистрибутивы размещают некоторые бинарные файлы в различных каталогах, что приводит к проблемам с переносимостью скриптов;
и это -- хорошо. Ибо вредоносные скрипты почти всегда не работают, а если даже работают, то не заражают другие системы. Ибо для запуска нужен живой админ, а он вирусы будет запускать лишь тогда, когда ему ЭТО действительно нужно.
разделение на /bin и /usr/bin в основном было сделано для этапа ранней загрузки системы - минимальный набор загрузочных файлов находится в /. Но это давно не работает, и соответствующая опция убрана из инсталлятора anaconda. Более того, размещение /usr на отдельной файловой системе вызывает проблемы при загрузе посредством systemd;
т.е. тут Леннарт сам признался, что он неосилятор, и не осилил сделать systemd, который работает везде? Простите, это система для systemd, или всё же наоборот?
разделение на минимальную систему в / и полную в /usr также стало бессмысленно благодаря initrd, а содержание двух уровней «минимальной загрузочной системы» - дурацкая затея;
Ложь. Рассчитана на тех леммингов, кто не понимает магии initrd.
существенно упростится установка «read-only» системы: так, libc и другие системные библиотеки будут доступны только на чтение, а /etc - на чтение и запись;
Ещё одна ложь. Чем /sbin/ тут мешает? Причём тут вообще это?
снятие снапшотов станет действительно атомарной операцией. В настоящее время btrfs требует 5 снимков - /lib, /lib64, /bin, /sbin и /usr вместо одного, что неудобно и может приводить к состояниям гонки;
ложь. Если свалить всё в одну кучу, то это ничего не изменит. Скорее наоборот. Проще сделать 5 непротиворечивых снимков, чем одну групповую фотографию. Это любой фотограф знает. На любой групповой фотке всегда кто-нибудь получится с закрытыми глазами (моргает), или просто с рожей, как у олигофрена.
существенно упростятся сетевая и контейнерная установки;
ложь. Просто ещё одна ложь.
сборочные скрипты упростятся: в частности, autoconf не знает о разделении на / и /usr, и для правильной работы с ними приходится прилагать специальные усилия;
autoconf И НЕ ДОЛЖЕН ЭТОГО ЗНАТЬ, дурья твоя бошка! Autoconf ставит ПО не туда, куда хочется Леннарту, а туда, куда хочет АДМИНИСТРАТОР. Если надо -- будет ставить в $HOME, и получится "портабельная программа".
эксперименты уже показали жизнеспособность предложенной схемы и отсутствие серьезных проблем;
В Windows 3.11 тоже не было никаких вирусов.
есть разработчик (Harald Hoyer), готовый выполнить необходимую работу.
[quote=Vascom]В связи с возможным объединением каталогов /bin и /sbin в один хотелось бы узнать почему кто-то против этого? Какие минусы вы в этом видите?
Да никаких рациональных минусов никто не видит. Простое верещание людишек с одубевшим мозгом.
Я бы вообще сделал так: /bin - для низкоуровневых системных бинарников, /usr/bin - для остальных приложений, /usr/sh - для пользовательских скриптов (баш, питон, etc). А то развели 6 каталогов для исполняемых файлов, ума палата просто.[/quote]
кстати да... было бы хорошо *SCRATCH*
накропанным пользователем скриптам нечего делать в одном каталоге с бинарниками, управляемыми пакетным менеджером.Сейчас роль такого каталога неофициально исполняет /usr/local/bin, но это уродство же.
То есть изначально имелось в виду разделение по пользовательский/системный? /home/user/bin с экспортом в PATH в помощь.
Всё же системный? Опакетить и ставить в системные /usr/bin.
Не хочется утруждать себя переустановками? Тогда /usr/local/bin на отдельном разделе.
Логично.
Я бы вообще сделал так: /bin - для низкоуровневых системных бинарников, /usr/bin - для остальных приложений, /usr/sh - для пользовательских скриптов (баш, питон, etc). А то развели 6 каталогов для исполняемых файлов, ума палата просто.
[quote="fragment"]накропанным пользователем скриптам нечего делать в одном каталоге с бинарниками, управляемыми пакетным менеджером.Сейчас роль такого каталога неофициально исполняет /usr/local/bin, но это уродство же.
То есть изначально имелось в виду разделение по пользовательский/системный? /home/user/bin с экспортом в PATH в помощь.[/quote]
За отсебятину в PATH вообще избивать надо. Если пользователей хотя бы 50 - будете экспортировать 50 путей?
А по вопросу объединения /bin и /sbin навскидку из технических резонов только возможность ограничения доступа к содержимому последнего. Из нетехнических -- требование дополнительных телодвижений для доступа к потенциально опасным командам.
а почему, если "ограничения", то это всегда "минус"? Почему MS-DOS не является идеальной системой, ведь там никаких ограничений нет, и любой процесс может получить доступ к любым файлам, и даже к любой памяти любого процесса?
Почему, начиная с Win95 стали вводить ограничения, и это -- хорошо? почему в WinNT (в т.ч. и в Windows8) даже доступа к руту НЕТ? Есть только "администратор", как в ubuntu, и доступ к административнному ПО только через костыли (как в ubuntu через sudo)?
Почему в венде новые ограничения == прогресс, а у нас как раз наоборот?
Если пользователей хотя бы 50 - будете экспортировать 50 путей?
Если сценарий нужен 50 пользователям -- это уже требует решения на уровне системы. Достаточно выбирать решения адекватные поставленным задачам, и всё получится.
Всё же системный? Опакетить и ставить в системные /usr/bin.
Системный и не хочется утруждать себя переустановками? Тогда /usr/local/bin на отдельном разделе.
а почему, если "ограничения", то это всегда "минус"?
Про минусы или плюсы речи не шло вообще, эти вещи сильно зависят от контекста/ситуации, достаточно вспомнить известное "что русскому хорошо, то немцу -- смерть".
"drBatty" написал:
Почему MS-DOS не является идеальной системой, ведь там никаких ограничений нет, и любой процесс может получить доступ к любым файлам, и даже к любой памяти любого процесса?
Для некоторых узких применений -- является и именно в силу описанных особенностей.
Разделение на /bin и /sbin в PATH ни от чего не защищает. Обычный пользователь не имеет прав записи в оба эти каталога. Так что подменить злоумышленник всё равно ничего не сможет.
Но он может изменить саму $PATH как угодно. Так что это не аргумент.
За отсебятину в PATH вообще избивать надо. Если пользователей хотя бы 50 - будете экспортировать 50 путей?
вообще-то, если ты не знал, то $PATH это окружение ПОЛЬЗОВАТЕЛЯ. Что он там пишет -- его личное дело. Если ему захочется, он туда _может_ вводить ВСЁ, что вздумается. В _любой_ ОС.
Это вообще, чисто для удобства. Если юзеру надо, он туда и /sbin/ может запихать, не вижу проблемы.
Ну так в чём тогда смысл раздельно иметь /sbin, если он ни чем не отличается от /bin?
И про то, что PATH это окружение пользователя, я естественно знал, о чём и написал. Не надо считать себя умнее других.
