OSDev

У меня -- спасёт, если дополнительно не указано, что программа запускается с административными привилегиями (естественно, сам пользователь должен быть при этом администратором; простой пользователь запустить по-любому не сможет). Так что от случайного уничтожения системных файлов или ещё что моя система защититься сможет, от намеренного со стороны администратора -- нет, да и не требуется это.

Ну почему же? Для этого делается developer build не для распространения, в котором защита отключена или ослаблена, а также во все сервисы напиханы дополнительные отладочные сообщения.


Конечно, архитектор ОС сам волен выбирать степень её отказоустойчивости.


Я сам ненавижу, когда ОС начинает мне указывать, что мне делать.
Но мне думается, такую архитектуру вполне можно сделать не в ущерб удобству. Тут вот в чём дело... абсолютный запрет распространяется лишь на те действия, которые и так ни один пользователь, находящийся в здравом рассудке, делать не будет. Вот не начнёте же вы гасить подряд или выборочно файлы в директории c:\Windows\System32\. И не станете их модифицировать. Это как раз те действия, которые делают злоумышленники, но не нормальные пользователи. Над абсолютным запретом на запись посторонних файлов в системные области я ещё размышляю, но в принципе, любой вариант серьёзными неудобствами не грозит. Либо запись разрешена, тогда всё превращается в свалку, которую администратор почистить может. Либо запись запрещена, тогда и чистить не от нечего.
По чтению же обязательно должен быть стопроцентный доступ.
Кроме того, запрет должен распространяться только на работающую инсталляцию ОС. Если ОС "пошла вразнос", грузимся с resque disk и в этой инсталляции имеем возможность ручками вправить любой файл.


Нелюбовь к паранойе возникает от того, что изначально Windows никак не разделяла данные пользователей и приложений и теперь вынуждена разделять их с кровью и тяжёлыми последствиями. А нелюбовь к Линуксу с аналогичной паранойей из-за децентрализованности разработки, в результате чего он превращается в свалку разработческую. Предполагается, что в системе с изначально заложенным разделением данных и централизованной разработкой паранойи не воникнет вообще. Иными словами, предупреждающие сообщения вообще не будут возникать, если только пользователь не попытается предпринять что-либо действительно неправильное.


Паскаль/Дельфи не люблю, на Аде давно не писал, но воспоминания негативные. Но не суть, не будем холиварить. Я лишь имел ввиду следующее. Эти блоки всё же не спасают от затуманивания смысла. Либо я пихаю, например, при каждой записи в файл обработку исключения, либо проверяю возвращённый функцией результат - объём кода не сокращается и читабельность на самом деле не повышается. Вот я например, сто раз пишу в файл, соответственно должен сто раз проверить исход действия и добавить (это только к примеру!) сто сообщений "Ошибка записи в файл!". Либо все сообщения/действия объединить в один кусок, на который передаю управление по goto (т.к. из самых разных мест функции). Ещё вариант - завожу новый тип исключения и возбуждаю его, но надо, чтобы вызывающая функция это исключение (или вообще все) перехватывала, иначе кирдык процессу. В общем, ни один из перечисленных вариантов мне не нравится. Не хватает элегантности и простоты чтения/понимания кода.


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

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Ну, в RSX-11, несмотря на крайнюю убогость тамошней системы разделения прав (с современной точки зрения, конечно), всё работало абсолютно надёжно и при этом не доставляло неудобств пользователям: всегда было понятно, что тебе можно делать, а что -- нельзя, как этим управлять и что делать, если стандартные правила защиты надо нарушить :) Насчёт Линуха ничего не скажу: не работал и тем более не администрировал. В Винде же... Да, возможности большие, но, поскольку всё это прикручивали с разных сторон и в разное время, система защиты получилась не шибко эффективная, неудобная в настройке, не до конца понятная даже довольно опытному программисту вроде меня (про простых пользователей не говорю вообще)... В общем, сделано плохо, хотя, возможно, при грамотном администрировании и обеспечивает надёжную защиту.



Возможно, не любите за то самое, за что люблю я -- строгость правил языков, навязывание программисту определённого стиля разработки (главным образом через необходимость использования пользовательских типов, особенно в Аде) и т.п. Но холиварить точно не будем :)



Ещё как спасают -- во всяком случае, в Дельфях и Аде. Например, можно сделать нечто вроде этого (за синтаксис не поручусь, давно уже писать на Дельфях не приходилось, а на Аде не было пока нужды использовать исключения, поэтому навык их применения пока не выработался):



В основном коде (между try-except) нет вообще ничего лишнего -- чистая логика для нормально работающей программы (предполагаем, конечно, что вызываемые подпрограммы не код ошибки возвращают, а кидают исключение -- но всё это легко делается в них и не загаживает основной код). Ну а после except идут обработчики разного рода ошибок. В общем, чёткое разделение основной логики и реакции на ошибки. Понятное дело, что придётся писать некоторое количество лишнего кода (те же обработчики ошибок), но без этого по-любому не обойтись. Зато он оказывается сконцентрированным в определённых местах, а не размазан по всей программе, да и основная логика обычно не загрязняется лишними проверками и т.п.

Другое дело, что подобный способ обработки ошибок не подходит для абсолютно любых задач, не всегда эффективен или удобен и т.п. Но основную массу потребностей, ИМХО, покрывает.

В Линуксе с защитой просто. Тупо, но просто.

Есть пользователи пользователи принадлежат группе.
Каждый файл имеет пользователя и группу.
На каждый фал имеются права на доступ: для пользователя, для группы и для всех остальных
Файл может читаться писаться исполняться.
rwxrwxrwx
Первая тройка это права для пользователя. вторая для группы третья для тех кто не относиться к пользователю или группе.
Ещё есть флаг смены прав. Когда права пользователя заменяются на права владельца файлом. Запуск от имени владельца файла.

Есть администратор, он имеет имя root. У администратора нет никаких ограничений.

В убунту, root имеет ограничения и для снятия используется команда sudo. Которая имеет свои настройки.


Для более тонкой настройки прав для файлов есть ACL. На каждый файл можно прописать настройки для любого пользователя или группы можно прописать свои правила. Не скажу во-все или не вовсех линуксах есть ACL. Если нету можно доставить.

Да я в курсе про архитектуру безопасности Линукс. Долгое время администрировал несколько линукс-серверов. Категорически не нравятся мне как традиционная rwx-rwx-rwx, так и надстройки ACL, в т.ч. и Убунтушный sudo, которые я упомянул ранее, как смена пользователя для выполнения административных действий.
Самая красивая и удобная система администрирования прав доступа была в старых Novell Netware, до того, как они перешли на Юниксовое ядро. Нетваревские серверы я тоже администрировал много лет и вспоминаю те времена с блаженной улыбкой :)


Не, не за это. Тут я как раз с радостью присоединюсь и поругаю С/С++ за полное отсутствие строгости типов, что часто приводит к глупым ошибкам, которые компилятор легко мог бы отследить, да синтаксис не позволяет.
Надо бы завести тему про ЯВУ, когда дело к ним подойдёт поближе, с конструктивным обсуждением.
Паскаль и ему подобные мне не нравятся за "слишком-много-букав". Моё мнение таково, что основная задача ЯВУ - прозрачность реализуемого алгоритма. Он не должен затеняться кучей лишней служебной информации. А получается, что такие самоочевидные и понятные вещи, как 2*2 тонут в обилии ненужного обрамления и сопровождения. А Ада в этом смысле - апофеоз многобуквия.


С обработкой ошибок в дельфи/аде не знаком, а в С++ почти так и сделано. Однако, есть два момента. Первый - необходимость заведения и определения нового типа исключения на свой программный чих и второй - всё равно try/catch размазывается по функции в виде отдельных блоков. На каждый вызов функций программисты используют свой блок.
Если бы я проектировал ЯВУ, я попробовал бы принудительно выделить блок Exception в конце функции, так, чтобы его нельзя было вставить в произвольное место кода.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

В RSX-11 с этим, возможно, несколько получше. Во-первых, все права делятся на четыре категории: 1) владелец; 2) член группы, в которую входит владелец, но который сам не является владельцем; 3) привилегированный пользователь (администратор); 4) все остальные пользователи. Во-вторых, самих прав тоже не 3, а 4: 1) чтение, 2) запись, 3) запуск/управление/ещё-там-что-нибудь (в зависимости от вида защищаемого объекта -- защита распространяется не только на файлы); 4) удаление. Соответственно, маска защиты объекта занимает одно слово (16 бит). Поскольку защита очень проста, её реализация компактна и не содержит ошибок: негде их там допускать, по большому счёту (во всяком случае, в проанализированной в своё время версии системы защита работала на 100% надёжно). Замечу, что эта защита одновременно позволяла защитить систему и других пользователей от непреднамеренных действий администратора: если у него нет прав, он не может, например, удалить файл. В то же время администратор, в отличие от остальных пользователей, имеет право всегда поменять маску защиты любого объекта, а значит, может сам себе дать доступ к этому объекту, если оно ему нужно.

Я детально тему защиты в своей системе пока не рассматривал: нужды в ней нет и в сколько-нибудь обозримом будущем не будет, а заняться есть чем и без неё. Тем не менее, по предварительным прикидкам, я планирую реализовать нечто вроде такого же механизма, только несколько расширенного и более гибкого. В частности, в RSX-11 пользователь является членом одной и только одной группы, причём группы не могут пересекаться или "вкладываться" друг в друга, а само членство в группе привязано к штатной файловой системе Files-11 (хотя защита распространяется, как уже говорил, не только на файлы). От подобных ограничений я, конечно, избавлюсь: в наши дни они выглядят нелепо (это не начало 1970-х, когда ОЗУ в 256 Кбайт считалось большим, а в мегабайт -- очень большим).

Ну, если желание есть, можно и завести. Холивар с переходом на личности пресеку, а более-менее конструктивное обсуждение никому не помешает, даже если будет эмоциональным :)



И согласен, и не согласен одновременно. Глупо спорить с тем, что запись программы на Паскале по числу символов будет длиннее, чем на Си. Однако эта "многобуквенность" обратной стороной имеет повышение читабельности. Возьмите, например, выражения на Си, состоящие сплошь из спецсимволов, или отсутствие ключевых слов then и do/loop, из-за чего условие в операторах if и while всегда должно быть заключено в скобки: зачастую на первый взгляд не очень-то и понимаешь, какой элемент выражения за что отвечает -- и это даже в том случае, если кодировщик не злоупотребляет вольностями сишного синтаксиса (что там можно накодить при желании, мы все знаем). Сюда же относятся и { } вместо begin-end: вторые однозначно длиннее, но на глаз вылавливаются из текста быстрей и проще. И дело здесь не в привычке: я несколько лет вынужден был писать на Си (надо ж на жизнь зарабатывать) и с огромным облегчением в конце концов избавился от этого. Понятно, что постоянно программируя на Си, я привык к { }, но begin-end всё равно мне кажутся более привлекательным вариантом. (Другое дело, что в Паскале их излишне много; в этом плане Ада с её end if, end loop и т.д. лучше).

Другая причина многословия -- это постоянные описания типов. В Си зачастую типы вообще описывать не надо или можно впихивать описание куда угодно, в Паскале и Аде -- нет (даже если два типа описаны текстуально одинаково, они будут считаться разными типами со всеми вытекающими, что иногда раздражает, но зато очень способствует надёжности).

В общем, недостатки паскалеподобных языков, ИМХО, прямо вытекают из их достоинств, причём достоинства однозначно перевешивают всегда и в любой ситуации, если говорить о собственно языке (а не о качестве конкретного компилятора, например). Ну а эпическая громоздкость адских текстов напрямую вытекает из очень подробных описаний типов, без которых там никуда -- но которые не только обеспечивают наивысшую среди всех "обычных" языков надёжность, но ещё и дают ряд средств, в принципе отсутствующих в других языках либо являющихся там нестандартными расширениями (типа возможности точно описать размеры типов, полей записей и т.п. с точностью до бита). То же самое можно сказать об адских пакетах: для хелловорлда они, конечно, усложняют жизнь, но в крупных проектах очень её упрощают. Недаром в Си++ выдумали отдельные пространства имён: проблему надо было решать (а вот решили её наихудшим из возможных способов -- правда, сохранив в результате почти полную совместимость с обычным Си).



Утверждать не буду, но вряд ли язык навязывает подобное использование try-catch. В Дельфях и Аде совершенно точно можно заключить в один такой блок хоть весь текст процедуры/функции, а ловить ошибки в самом его конце. Так что, может быть, здесь причина в индусских быдлокодерах, неправильно использующих инструмент?

Что же касается необходимости объявления нового типа исключения, то от него, вообще говоря, никак не избавиться: должно же быть какое-то средство для идентификации причины возникновения этого самого исключения. В Дельфях для этого объявляется новый класс, порождённый от стандартного класса Exception или от какого-либо из его потомков (компилятор "завязан" на эти классы). В Аде лучше: там объявляется нечто вроде MyExpt : exception -- и всё. Что скрывается за этим exception, знает только компилятор (в Аде это не название типа, как в Дельфях, а зарезервированное слово, имеющее для компилятора строго определённый смысл).



ИМХО, это было бы ненужным ограничением. Иногда действительно надо заключить в такой блок лишь некоторую часть подпрограммы, так зачем это запрещать?

Система безопасности RSX-11, как и Линукс (без ACL) обладает тем принципиальным ограничением, что не различается членство в разных группах. Т.е. предполагается, что че-к - участник только одной группы. Очень глупо и недальновидно.
В системе безопасности Windows мне не нравится то, что для каждого объекта права прописываются индивидуально. Т.е. появился в папке файл, - для него индивидуально прописываются унаследованные права. При перемещении файла в другое место он потащит за собой старые права, вместо того, чтобы наследовать права нового размещения. Это просто ужасно! Если я переношу кусок дерева файловой системы с тысячей файлов в новое место, причём для этих файлов я не назначал прав доступа, то я обнаружу, что на новом месте у них не появились права доступа, связанные с новым размещением! Более того, сохранились старые права! Иными словами, чтобы передать файл от пользователя А пользователю Б мне совершенно недостаточно переместить файл из папки А в папку Б. Мне надо открыть свойства файла и применить к нему наследованные права. В случае тысяч файлов в куче папок это превращается превратиться в головную боль и потенциальную брешь в доступе. В системах с NTFS я для решения этой проблемы обычно держу дополнительный раздел FAT32 и переношу файлы в две стадии - сначала со старого места в раздел FAT, для аннулирования старых прав, затем в новое место в NTFS, где они наследуют новые права. Блин, поубивал бы разработчиков!
Повторюсь, - более грамотной и удобной системы прав доступа, чем в Novell Netware, не встречал. Каждый, кто планирует разделение прав доступа, просто должен поставить эту систему и покатать её на практике.
В ней права доступа задаются явно на объекты - директории и индивидуальные файлы. Наследованные права не хранятся индивидуально у каждого объекта, а вычисляются по факту текущего положения объекта в общей йерархии. Сменилось положение - автоматически меняются права.
Субъектами прав являются пользователи и группы. У каждой группы есть менеджеры, которые в рамках прав, отпущенных им вышестоящим субъектом могут назначать права доступа для своей группы в подконтрольной им зоне. Подконтрольность определяется их собственными правами, т.к. они сами могут быть членами каких-то групп или иметь персонально назначенные права. Персональные назначения прав (для пользователя) имеют приоритет перед групповыми. Вершиной всего дерева прав является, естественно, администратор. В рамках данной системы очень просто реализуется произвольный масштаб организации прав доступа. Так, админ, выделяет несколько папок, создаёт основные группы и может назначить для них менеджеров с правом доступа в соответствующие папки. Менеджер может самостоятельно набирать членов своей группы, создавать в рамках своих полномочий дополнительное разделение прав, новые группы пользователей и назначать менеджеров следующего уровня. И т.д. При этом ни один нижестоящий уровень не может перебить права, назначенные вышестоящим.


Вот вы критикуете предложения об ограничении области обработки исключений, как слишком жёсткие, а вместе с тем критикуете С за вольность. Я думаю, что инструмент хорош возможностями, которые предоставляет, а программист хорош тем, как он использует эти возможности. Синтаксис языка плох тогда, когда он провоцирует программиста на использование плохих решений. Так, можно структурно программировать на фортране или на бейсике, но сами языки к этому не располагают. Если в си написать конструкцию *a++ = *b++, то она страшна с только непривычки. На самом деле с языковой практикой воспринимать такую конструкцию оказывается проще, чем три разных последовательных оператора.


Это ОЧЕНЬ субъективно. По мне, так ровно наоборот.
По остальным моментам - я не спорю, что С/С++ во многом плохи. Но и идеального языка я пока не вижу.


Вот, адский подход - вполне достойная альтернатива. Значит всё-таки можно :)


Так можно сделать это нестрогим ограничением. Например, хочешь обработку исключения только в этом участке кода - выдели его в отдельный логический блок. {} или begin/end, кому как удобней, и в нём назначь перехват исключений. Я к тому, чтобы синтаксис язык не провоцировал программиста на неправильное использование.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Для конца 1960-начала 1970-х -- нормально. Для современности -- естественно, очень ограниченно.



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



Увы, дела не имел, не знаю... Так что спасибо за описание.



Если язык слишком сильно ограничивает -- обычно это уже плохо. Например, нет смысла требовать выравнивать текст программы строго определённым образом, хотя таким требованием можно было бы запретить откровенно плохой стиль программирования, ну и т.д. В общем, нужен некий разумный подход.



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



Может быть, и более-менее объективно: это надо проводить исследования на большой группе участников, чтобы выявить, как кто реагирует. Хотя, понятное дело, индивидуальные особенности остаются, и даже если для 90% лучшим окажется один вариант, всегда найдутся 10%, предпочитающих другой...



А его и не может быть, поскольку улучшение в одном почти всегда вызывает ухудшение в другом. Тут уж как приоритеты расставлять. Если выбирать необходимость в куче описаний для Ады и простоту адресной арифметики в Си, я даже для низкоуровневой по сути задачи выберу Аду: пускай текста будет больше, но надёжность важней, а искать идиотские ошибки из-за дурного синтаксиса у меня желания нет :) Однако постоянно писать приведения типов, конечно, напрягает...



Может быть, может быть...

Наследование прав в винде очень кривое. Наследование работает для вновь созданных объектов. Либо я могу принудить винду поправить права доступа в соответствии с наследованием. Но если объект уже несёт на себе какие-то права, то они остаются. Чтобы применить наследование, я должен кликнуть свойства на скопированных файлах/папках и явно указать привести права доступа в соответствии с наследованием. Вот сейчас попробую пояснить на пальцах всю кривизну.
Как в винде. Есть две папки - "A" и "В", принадлежащие одноимённым пользователям. Пользователь "А" создаёт файл "х" в своей папке. При этом он не задаёт на файл никаких специальных прав. Однако при создании файла на него скопируются права, унаследованные от папки "A". Далее администратор системы по просьбе пользователей переносит файл из папки "А" в папку "В". Логично (т.к. индивидуальных прав на файл не задавалось), что пользователь "В" сразу мог бы получить доступ к файлу. Однако, он вместо доступа получит $%й, так как файл потянул за собой старые права доступа. Они оказались пришиты к нему в момент создания файла. Теперь администратору нужно кликнуть свойства файла и сказать: "А унаследуй-ка ты права от той папки, где сейчас находишься!" Только после этого пользователь В может начать работу с файлом. Сия "особенность" больше всего прикалывает в версиях систем от мелкософта, где считается, что пользователь вообще не должен иметь доступа к назначению прав, т.е. в домашних и начальных версиях закладка прав доступа отключена :) И вот смотришь, как мучается че-к с файловой системой NTFS, пытаясь передать файл другому пользователю :)))
Как в нетвари. При создании файла "х" его индивидуальные права не заданы и он полностью наследует права от папки "A" по факту своего размещения в ней. После переноса в папку "В" на него автоматически распространятся права папки "В" и второй пользователь тут же приступит к работе с файлом. Всё просто и очевидно.
Другой неприятный момент, тоже, так сказать, "особенность" того же плана.
Как в винде. Пусть у меня есть дерево файлов. Тут я решаю добавить права доступа к папке. Открываю свойства папки, добавляю новые права, закрываю. Пользователи матерятся, т.к. ничего не изменилось. Я хлопаю себя по лбу, ещё раз открываю свойства и говорю: "Применить права доступа ко всем дочерним объектам!". В другой раз обнаруживается, что документы в одной из папок составляют коммерческую тайну. Тогда я закрываю доступ к папке, а через месяц меня с треском увольняют, т.к. злоумышленники всё равно прочли содержимое файлов из-за моей забывчивости :)
Как в нетвари. Добавляю,убираю права доступа на папку, тут же вся подлежащая структура, кроме тех её элементов, на которые явно отдельно заданы права, получает соответствующий доступ или лишается его. Просто и очевидно.

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


Я думаю, во всех вариациях есть определённый компромисс. И можно применить определённые критерии. Например:
1. Массовость симпатии.
2. Скорость выполнения задания на языке.
3. Количество ошибок, допущенных при реализации задачи.
Вообще говоря, есть даже соответствующие конкурсы. Так например, в среде разработчиков микросхем доминируют два языка программирования топологии (HDL - hardware description language) - Verilog и VHDL. Verilog - аналог С. VHDL - аналог Ады. Можно себе представить, какие холивары разгораются между ними :))) Так эти холивары привели к проведению ежегодных командных соревнований. Всем участникам раздаётся задание и они должны в отведённое время его решить. В конце подсчитывается, сколько участников успешно с ним справились. Я полагаю, что если задаться целью, то можно проводить (а может и уже проводятся?) аналогичные соревнования по традиционным ЯВУ.
Но надо сказать, что в большинстве случаев критика многих языков вполне оправдана, соответственно, можно эту критику учитывать при разработке новых ЯВУ. Не удаётся найти компромисса только по субъективным моментам, как например, использование скобок или ключевых слов begin/else. Таким образом, только в данных моментах требуется более детальное и массовое исследование, а в других, я думаю, достаточно положиться на здравый смысл.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>