ну дык о том я и говорил.Про минусы или плюсы речи не шло вообще, это вещи сильно зависят от контекста/ситуации, достаточно вспомнить известное "что русскому хорошо, то немцу -- смерть".
LinuxForum.Fans
Объединение каталогов для исполняемых файлов
Автор: drBatty
70 сообщений
1590 просмотров
Почему MS-DOS не является идеальной системой, ведь там никаких ограничений нет, и любой процесс может получить доступ к любым файлам, и даже к любой памяти любого процесса?
Для некоторых узких применений -- является и именно в силу описанных особенностей.
нет ничего проще, чем работать под рутом. И именно так оно и сделано например в LiveCD. Во встроенной технике -- тоже часто так. Ломать -- не строить.
Расскажи, чем твоя MS-DOS лучше GNU/Linux в этом смысле?
Давайте не отвлекаться от темы.
Разделение на /bin и /sbin в PATH ни от чего не защищает.
и НЕ ДОЛЖНО защищать от доступа
Юзер ВСЕГДА может получить доступ к /sbin/*. При чём тут твоё объединение???
Обычный пользователь не имеет прав записи в оба эти каталога. Так что подменить злоумышленник всё равно ничего не сможет.
сможет. Права записи не имеет, а вот ПОДМЕНИТЬ может.
Вот именно!Но он может изменить саму $PATH как угодно. Так что это не аргумент.
Теперь ответь мне на вопрос: КАК подменить $PATH таким образом, что-бы выполнилась НЕ ТА КОМАНДА
[console]/sbin/fdisk -l[/console]
???
см. выше.Ну так в чём тогда смысл раздельно иметь /sbin, если он ни чем не отличается от /bin?
И про то, что PATH это окружение пользователя, я естественно знал, о чём и написал. Не надо считать себя умнее других.
Давайте не отвлекаться от темы.
Если сценарий нужен 50 пользователям -- это уже требует решения на уровне системы.[/quote][quote="fragment"]Если пользователей хотя бы 50 - будете экспортировать 50 путей?
А я о чём? /usr/sh был бы прекрасным решением.
Я посмотрел выше. Там сказано, что это для безопасности пользователя. Но мы уже выяснили, что безопасность тут ни при чём. Пользователь всегда может запустить любые файлы из каждого рассматриваемого каталога. И даже!!! может добавить это сам в свою переменную окружения.
К тому же современным пользователям довольно часто нужны программы, лежащие сейчас в /sbin, так что нет смысла затруднять ему к ним доступ. И ни одной из тех программ нельзя навредить системе не имея соответствующих прав.
Так зачем же разделять эти каталоги?
fragment, зачем? Почему бы этот скрипт не опакетить и положить аккуратно в /bin?
Так зачем же разделять эти каталоги?
Незачем. Но ведь в стандарте есть sbin, а убрать его предлагает Поттеринг, а Поттеринг плохой потому что Поттеринг, тяф-тяф-тяф-тяф.
fragment, зачем? Почему бы этот скрипт не опакетить и положить аккуратно в /bin?
Нечего всякой юзерской скриптовой шелухе делать в /bin. Да и потом - как вы будете определять грань, после которой скрипт уже нужно опакечивать?
В /bin может положить что-либо только админ, а не юзер. Вот админ сам и определяет грань - класть туда что-то или нет. И речь шла выше, когда скрипт нужен 50 пользователям и более.
Кстати, аргумент про свалку/помойку тоже не подходит. Например сейчас у меня в /bin 4311 файлов, а в /sbin 859. Так что даже без всяких пользовательских скриптов - это уже две свалки, при этом там бинарники лишь из официальных пакетов.
Эм выше я не совсем точно а точнее выразился обсолютно не так что я имел виду изначально.
Как по мне было бы не плохо ввести ну хотя бы возьмем уже упоминавшийся ранние каталог /usr/sh , для именно ПОЛЬЗОВАТЕЛЬСКИХ скриптов написаных на bash, python, etc.
А про /bin, /sbin я пока не решил на чьей я стороне :D
В /bin может положить что-либо только админ, а не юзер.
Вот и нечего админа дёргать по пустякам :)
Кстати, аргумент про свалку/помойку тоже не подходит. Например сейчас у меня в /bin 4311 файлов, а в /sbin 859. Так что даже без всяких пользовательских скриптов - это уже две свалки, при этом там бинарники лишь из официальных пакетов.
Свалка определяется не количеством.
Пользователи вообще не имеют права писать в /usr. Для пользовательских скриптов обычно используют ~/bin или ~/.bin или типа того.
А чем же определяется свалка? Каков критерий?
А я о чём? /usr/sh был бы прекрасным решением.
а тебе кто-то мешает сделать /bin/sh? Сделай. Почему нужно объединить для этого /bin и /sbin?
Пользователи вообще не имеют права писать в /usr. Для пользовательских скриптов обычно используют ~/bin или ~/.bin или типа того.
Это очевидно идиотское решение. Во-первых, засорять PATH не комильфо, во-вторых, если кому-то понадобится тот же скрипт - будет ненужное дублирование. Мелочь, а некрасиво.
А чем же определяется свалка? Каков критерий?
Бесструктурностью и беспорядком.
Ну а какой порядок может быть в 800+ независимых файлах в одном каталоге?
Ну а какой порядок может быть в 800+ независимых файлах в одном каталоге?
Невидимый простому глазу :D
Там сказано, что это для безопасности пользователя. Но мы уже выяснили, что безопасность тут ни при чём.
ты читать разучился?
Это ТЫ голословно высказал (повторил точнее) догму, что "безопасность не при чём".
Ну и что?Пользователь всегда может запустить любые файлы из каждого рассматриваемого каталога. И даже!!! может добавить это сам в свою переменную окружения.
Повторить ещё раз? ПОЛЬЗОВАТЕЛЬ МОЖЕТ!!!
А вот вредоносный скрипт или злоумышленник -- не может.
К тому же современным пользователям довольно часто нужны программы, лежащие сейчас в /sbin, так что нет смысла затруднять ему к ним доступ. И ни одной из тех программ нельзя навредить системе не имея соответствующих прав.
примеры будут, или это не дело леммингов, свой бред обосновывать?
Так зачем же разделять эти каталоги?
не разделяй. Только ты так и не объяснил, ЗАЧЕМ?
Незачем. Но ведь в стандарте есть sbin, а убрать его предлагает Поттеринг, а Поттеринг плохой потому что Поттеринг, тяф-тяф-тяф-тяф.
т.е. аргументов не будет, только тявканье? Аватара символизирует...
Кстати, аргумент про свалку/помойку тоже не подходит. Например сейчас у меня в /bin 4311 файлов, а в /sbin 859. Так что даже без всяких пользовательских скриптов - это уже две свалки, при этом там бинарники лишь из официальных пакетов.
знаешь, количество помоев не является определением помойки. Помойка -- это когда всё в одной куче. И не важно, сколько этого "всего".
Как по мне было бы не плохо ввести ну хотя бы возьмем уже упоминавшийся ранние каталог /usr/sh , для именно ПОЛЬЗОВАТЕЛЬСКИХ скриптов написаных на bash, python, etc.
у меня есть $HOME/srcipts/ ЧЯДНТ?
Это очевидно идиотское решение. Во-первых, засорять PATH не комильфо, во-вторых, если кому-то понадобится тот же скрипт - будет ненужное дублирование. Мелочь, а некрасиво.
во первых, $PATH изначально придуман, что-бы его "засорять". ИЧСХ -- юзерам.
Во вторых -- не нравится так, сделай общий каталог, в который один (или многие) юзер будет иметь право класть скрипты. А все остальные только запускать. Не вижу проблемы. Где ты видишь "дублирование"?
Бесструктурностью и беспорядком.
именно так. В помойке один бак, и любой бомж имеет в этот бак полный доступ. Или там три бака, но общий доступ у всех.
А вот порядок -- это когда всё в шкафах и ящиках, и каждый юзер имеет свою связку ключей, к некоторым ящикам. Да, неудобно лазить в чужой ящик, но это не баг, а фича.
Ну а какой порядок может быть в 800+ независимых файлах в одном каталоге?
какая разница, сколько у меня инструментов? Какая тебе разница, что они на 95% для тебя не нужны?
Вот именно, так зачем держать их в отдельном каталоге? Большинству что в первом не нужны 95%, что во втором.
Вот именно, так зачем держать их в отдельном каталоге? Большинству что в первом не нужны 95%, что во втором.
нет, я не согласен с твоей аргументацией.
Это твоё "большинство" должно идти мимо стройными рядами. Их мнение не интересно. Не интересно прежде всего им самим. Им глубоко параллельно, сабж или не сабж. Можешь сам спросить.
Войдите или зарегистрируйтесь, чтобы ответить.
