Ну чтобы не бояться не быть полезным - Unix must die
August 12th, 2008
11:07 pm

[Link]

Previous Entry Add to Memories Tell A Friend Next Entry
Unix must die

Yes. Set-uid shell scripts work on HP-UX, for example, the kernel of
which is a derivative of 4.2 BSD. ("Work" used loosely here, because
it is a bad thing.)

However, setuid shell scripts are such a security hole that they
should never exist. Much of the time spent by the security scanners
for unix scan for just such problems.


Unix programming and design are partially crazy!

What do Unices suggest? Two alternatives are considered (a bad thing and a bad thing):

  • You can write in C; it's one of the most distressful tasks to write a decent program in C! (But kernels need this.) A program in C should be suspected to be wrong and insecure. But if you have checked it 100 times, go ahead and make it a setuid-root program (when you need a setuid-root program).

  • Or (what have Unices achieved as an alternative?), also, there have been created "shells", "bash" is a very poplar one. The design of its syntax is so braindead that nobody has enough will to write correct bash programs, most of them are well understood to work just in 90% cases (e.g., having to type all the quotation marks in a line like file "$(which "$cmd")" kills me whenever I need it). Everybody feels happier when he writes trash as shell scripts instead of correct code. And the Unix Designers have decided to be fascists and disallow setuid-root interpreted programs at all in favor of security!



Binary code can't save you; high-level languages could save you from many low-level errors, no matter whether interpreted or compiled! But Unices have born the monster "Bourne-Again Shell" instead of some sane popular high-level language.

And that's in XX1 century!

The minorities which understand sane high-level languages are suffering from the restrictions done for the dumb majority.

Revolution or death (of Unix)!

(BTW, the Plan9's shell looks nicer, I'll try to get used to it.)

Current Mood: predatory

(6 comments | Leave a comment)

Comments
 
From:[info]qulinxao
Date:June 25th, 2011 - 08:45 am

результат осмотра rc?

(Link)
ну и как rc?
и обозримость plan9?
[User Picture]
From:[info]imz
Date:July 4th, 2011 - 06:49 pm

what I imagine a good shell of the future to be like.

(Link)
Да никак! Мне было не охота на них смотреть ближе, да и себя к чему-то принуждать.

Слишком ленив для революции :(

На самом деле, я ещё подумал и другие вещи с тех пор касаемо этих вопросов на практике.

Например, скрипты -- это первое -- (для себя) я предпочту попросту писать на другом высокоуровневом языке, а не bash. Выбор большой (глядя вокруг): кто-то сразу думает в таких случаях на python, я -- может, на haskell или lisp. Когда-то awk сгодится. Хотя привычка всё тянет к bash, на котором как что писат уже в голове сидит и требует сознательного обдумывания... :(

Они мне пока ближе, чем rc; зачем мне сейчас в первую очередь на rc смотерть?..

Ну а что же -- это второе -- использовать в качестве интерактивного shell-а?.. Ну я пока то bash (для администрирования), то eshell в Emacs при пользовательской работе использую. Но он недоделанный (отстой на самом деле из-за его убогости полный!), зато внутри Emacs и можно привычным образом манипулировать с текстом, который ввод или вывод действий в shell-е, а также связываться с другими буферами и пр. емаксовыми механизмами.

Опять же, некто мне говорил, что мне могло бы понравиться что-то вроде ipython или последнего shell-а от Microsoft (извините, не запомнил названия) -- при моём стремлении к чистототе и простоте абстракций, структур всяких. Я не пробовал.

Ещё я порыскал, бывают всякие задумки интерактивных shell-ов над haskell. Я хотел попробовать, но потом меня стали посещать мысли, что не совсем идеал в моём представлении, потому что дело не только в технике программирования и парадигме мышления и программирования (строки, структуры/записи/объекты, функции или -- быть может даже -- неизвестные и поиск решений, т.е. "логическое прогр-е"), и вменяемом синтаксисе, но в самой организации дела составления своей команды, опирающейся на плечи ОС.

(Так что зачем тратить время на освоение того, что не продвигает нас в сторону моего идеала... А ещё я параллельно заметил, что предлагаются интерактивные shell-ы c упрощённым и более вменяемым синтаксисом вроде fish -- почему пока нет идеала не попробовать его для простых нужд, чтобы не раздражаться постоянно на уродство bash?.. С одной стороны, оно, конечно, вроде как позиционируется для новичков. Зато не будет бесить своими "$("" '' \\)" "${@}"!)

Так вот.

Я подумал, что я хочу, чтоб интерактивный shell был вроде системы построения желаемой команды путём поиска вывода желаемого.

Ср. coq и т.п. proof assistants.

Желаемое -- ну для начала можно считать, что это -- тип. (А тип -- как учит Хаскелл Карри -- это утверждение, т.е. в той или иной степени грубости -- это семантика задуманного.)

Аксиомы в нашей системе вывода -- это уже возможности (уже реализованные программы), предоставляемые ОС.

Правила вывода -- всяческие способы комбинирования простых команд в более сложные. Ну там по сути всякие: ; | & || && $() () xargs и т.п. По этим правилам строится сложная команда, и про них известно, какое преобразование в семантике они делают: как из семантики частей получается семантика всего целого.

Когда нашли вывод для желаемого, одновременно построили команду, его реализующую. (Curry-Howard correspondence)

И эта система помогает находить пригодные тебе программки в твоей ОС, дистрибутиве -- не нужно помнить их названия, какая что полезного делает и какие аргументы. Это должно быть формализовано (на уровне набора аксиом это ппопадает в систему вывода нашу). -- Большая работа!

А то сейчас уже есть миллион всяких программ, но ими реально воспользоваться -- надо же человеку прежде с ними познакомиться.

Ср. hoogle -- там поиск по грубым haskell-овским типам, но и при такой степени грубости семантической стороны в нашей системе уже было бы неплохо. Из миллиона наш "shell assistant" уже предложит по типу десяток-другой программок, которые могли бы сработать (судя по типу) в решении нашей задачи, а мы выберем по нашему человечьему разумению. (И нет, в hoogle, конечно, нет поиска вывода, т.е. построения сложной программы из доступных простых; это я просто в качестве примера того, что при обилии и богатстве библиотечных штуковин hoogle сильно поможет найти нужную тебе хотя бы просто по типу. А для примера построения правильной программы из кусочков -- см. coq и т.п.)

Эти мысли я сформулировал для себя прошлой весной (2010). Но рассказав Кириллу Маслинскому, я услышал в ответ очень хорошее замечание: что интерактивным shell-ом человек вообще-то пользуется примерно так, как человеческим языком, т.е. не осознавая, как он что там по каким схемам строит, а просто обращаясь с теми конструкциями, которые он усвоил, ради достижения всяких целей.

И явно работать со схемами построения -- это совсем не человеческая языковая способность, поэтому оно может не сработать и не прижиться в качестве интерактивного shell-а. Может быть... но попробовать я бы хотел.

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

Правда, мне не хочется осоваивать "лексикон" из миллиона написанных Unix программ. Ну миллион, это я преувеличиваю, но дясятки тысяч. Мой интерактивный шелл -- это, получается, не шелл простого носителя языка, а шелл грамматика, читающего и пишущего на новом для него языке благодаря уму и сообразительности, при помощи инструментов -- логики, программы-системы вывода и формализованного словаря. Т.е. не оттачивающего мастерство беглой речи, а каждый раз решающего всё же той или иной хитрости задачу, когда даёт шелл-команду.)
[User Picture]
From:[info]imz
Date:July 4th, 2011 - 07:22 pm

typos

(Link)
typos fixed:

Хотя привычка всё тянет к bash, на котором как что писать уже в голове сидит и не требует сознательного обдумывания... :(
[User Picture]
From:[info]imz
Date:July 4th, 2011 - 07:19 pm

plan9? Do I need it as a user and a programmer and a sysdamin?..

(Link)
Ну а про plan9...

я тоже его так и не пробовал.

Во-первых, я как-то не верю, что будет комфортно жить с системой, которой так мало людей занимаются (по сравнению с Linux, *BSD). Хотя бы даже проблема драйверов! У меня, пока я использую даже Linux с конца 90-х, случались проблемы с драйверами. (pl2303 вот или как там его сейчас работает и бывал/бывает полезен для соединения всяких телефонов и т.п. с компом по проводку, но когда я впервые прикоснулся к нему и такому устройству, он падал!.. Там была какая-то ошибочка в коде, я почитал и послал замечание. Но это же совсем некомфортно, ждать какого-то подвоха от драйверов.) Поэтому я не верю в то, что мне можно попробовать plan9.

Во-вторых, да так ли мне нужно, чтобы всё было чисто концептуально, всё там было файлом в ОС и всё такое?.. Ну да, при решении некоторых задач, близких к ОС, было бы, наверное, приятнее, если бы ОС была концептуальнее. Но меня сейчас больше интересуют не такие задачи. Потом куча софта написана для Unix, а не для этой концептуальщины. Я этого не почувствую. (Это по сути то же соображение -- про то, что меня не такие задачи интересуют -- ещё раз.)

Ну а в каких областях я мог бы почувствовать разницу?

При работе через сеть. Скажем, с удалёнными файлами. Ну мне Emacs-а более-менее хватает. Там тоже всё более-менее унифицировано. TRAMP, скажем. Хотя Emacs такой корявый монстр, что... как же он будет жить и развиваться?..

Ну, всё, что через сеть, как-то решается специализированными программами.

Пока про plan9 мне интересно почитать, но попробовать у себя не очень хочется, потому что унификация всего сетевого и файлового, мне кажется, мне мало что может дать.

Надо каждую конкретную задачу обсуждать, и не забывать посмотреть, какой к ней милый подход может быть был предложен в plan9. Редактирование удалённых файлов я уже назвал, но мне хватает Emacs. А вот, скажем, ещё к backup-ам там предложен подход (забыл ключевое слово... rdup?) -- как общая схема интересно, но ведь ничего не завязано на plan9. Можно rdup или аналогичные штуки реализовывать где угодно. Простого rdup всё равно не достаточно (мне -- скажем, для предоставления для публики заbackupленных данных в разных видах в разных местах).

Извините, я не стал революционером на своём компе.
[User Picture]
From:[info]imz
Date:July 4th, 2011 - 05:39 pm

meanwhile, I have learned there used to be a sane reason for disallowing setUID scripts!..

(Link)
Meanwhile I have learned a propos the issue of the assumed insecurity of setUID scripts that not only the absence of trust in the interpreter and its programmer is the reason for disallowing setUID scripts, but also there used to be such a reason as a possible race attack on the execution of "shebangs" -- http://unix.stackexchange.com/q/364/4319#2910 :

If setuid scripts are allowed with this implementation, an attacker can invoke an arbitrary script by creating a symbolic link to an existing setuid script, executing it, and arranging to change the link after the kernel has performed step 1 and before the interpreter gets around to opening its first argument. For this reason, most unices ignore the setuid bit when they detect a shebang.


Great to know!

(But as that explanation notes there have been invented safe mechanisms to achieve our goal here; so we still should hate modern Linux for this restriction, unlike *BSDs and Mac OS X, probably.)
[User Picture]
From:[info]imz
Date:July 8th, 2013 - 04:52 pm

+1 reason why bash is terrible and unsafe

(Link)
bash is terrible and unsafe (once again) because it proceeds even after a syntax error! -- http://unix.stackexchange.com/q/82224/4319

I'm thinking again about an alternative better programming language for Unix scripts.
My Website Powered by LJ.Rossia.org