Изменения в «PspoClasses/080729/01RunLevels»

Уровни выполнения

Здесь приведён очень краткий пересказ того, что такое урвни выполнения, более подробно см. учебник. Уровни выполнения есть некая абстракция, которая упоминается в конфигурационном файле init, inittab. Это замороченная штука, довольно старого фрмата, простой смертный там ничего менять не должен, за исключением уровня выполнения по умолчанию, который указывается в строчке init-default. Там есть ещё мнго всякого интересного, там описывается, какие терминалы, склько консолей... в общем, описание процесса init в самом старте системы. В частности, в inittab несколько раз упоминается понятие "уровень выполнения", в частности, используемый по умолчанию (вышеупомянутый init-default), и уровни выполнения с шелльными скриптами, которые им соответствуют. Дальнейшее описание лектор откладывает на книжку, упомянет только, что, так уж сложилось по традиции, что переход с уровня выполнения на уровень выполнения означает прибивание всех служб, которые запущены на одном уровне, но не должны запускаться на другом (в альте это регулируется командой chkconfig).

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

Уровни эти 0..6 (7, 8) можно c натяжкой воспринимать как прфили работы одной и той же системы. Исторически сложилось, что уровень 0 - полная остановка системы с выключением, если это возможно, 6 - перезагрузка системы (остановка и загрузка заново на уровень по умолчанию). Что касается всех остальных уровней, есть довольно давняя традиция, что уровень 1 - однопользовательский режим, 2 - многопользовательский режим без сети, 3 - многопользовательский режим с сетью. Остальное никак не специфицированно, хотя традиционно считается, что уровень 5 - это многопользовательский режим с сетью и графическим интерфейсом. Кажется, седьмой уровень - это уровень инсталлятора. Пятый и седьмой уровень нигде не стандартизованы, и вообще непонятно, почему так кто-то решил; видимо, для современных систем, где наличествует графика, пятый уровень должен отличаться от третьего.

Если приостановиться и подумать, зачем так устроено и какое в этом удобство, мы поймём, что никакого удобства в этом нет. Давным-давно уровни не проходятся поряд, давным давно не бывает такого, что наша система сначала входит в первый уровень и запускает службы, необходимые на первом уровне, потом переходит с первого на второй уровень, дозапусковывает службы, необходимые на втором уровне и т.д. В реальности делается так: убиваются все службы, которые должны убиться, а потом они запускаются заново, или убивается некоторая высчитанная разница... Как-то так. И можно переходить с любого уровня на любой. То есть, фактически, никакого понятия "уровень" уже нет. Это просто некий профиль - однопользовательский, многопользовательский там, многопользовательский с сетью... Совершенно неочевидно, почему этих профилей должно быть 4, а не 10, не 2. В системах BSD есть только 2 уровня - однопользовательский, то есть тот, где ничего нет, только шелл да консоль, и штатный. Предполагается, что если нужно делать что-то так, чтобы никто не беспокоил, то переходишь в однопользовательский режим и всё делаешь.

При этом совершенно непонятно, зачем это нужно. Дело в том, что init был написан примерно тогда, когда и первое ядро UNIX, а может и раньше. Надо напомнить, что Кен и Деннис в рабочее время работали над ОС multics, где работали военщики, где много теории было реализовано. Есть легенда, что эта система была доведена до рабочего состояния, сдана заказчику и существовала в единственном экземпляре, так как была построена по нетиражируемым технологиям. Была история, что деннис назвал юникс так, чтобы поглумиться над названием multics. Дело даже не в этом, а в том, что ОС малтикс была написана по заказу военных, которые любят разделение доступа не демократичное, а сообразно правилам, в российской терминологии - мандатный доступ (нечто вроде ACL, только организованное по специальным алгоритмам). С этой точки зрения, когда мы определяем права доступа субъектов системы к объектам, важно разделдение в категорях самих субъектов.

• Может быть так, что система работает так, что при каждом сеансе доступа к данным есть только один субъект. С точки зрения секретности, если есть один субъект, то что бы он ни делал с данными, это его проблеммы. Поэому нет необходимости защищать данные от произвольного доступа. От непроизвольного стоит - когда у нас есть много процесссов, неплохо, чтобы они не портили свои данные случайно.
• Следующий уровень, на котором мы должны гораздо больше безопасности разводить - когда есть много субъектов одного класса. Считается, что у них нет серъёзных поражений в правах, условно говоря, это - некая команда, они имеют одинаковые уровни доступа к документам и т.д., но было бы неплохо защитить их данные от доступа друг друга, если они этого не хотят или если это запрещено уставом. Мы должны выработать механизм защиты от произвольного доступа и на этом остановиться. То есть, есть правило, определяющее, как организуется защита от произвольного доступа, в случае юникса вы руками выставляете права даоступа на свои файлы, в случае системы, где это регулируется сверху, будет некая матрица, по которой это будет видно.
• Ещё более сложная ситуация наступает, когда в системе работают пользователи разных категорий, то есть такие, алгоритм определения прав доступа которых к объектам системы для каждой группы пользователей различен. Есть серьёзные пользователи, есть левые пользователи и т.д. То есть, в ситуации, когда к компьютеру присоединено двадцать терминалов, на каждом из которых сидит по одному человеку, это пользователи одной категории, а если к компьютеру может присоединиться кто угодно, мы явно имеем другую ситуацию - мы имеем небходимость разделения пользователей по категориям. Некоторые, которые подтвердили свою высокую категорию доступа, имеют одни права, некоторые - другие... Что при этом присходит с системой? Усложняется мехнизм идентификации (в случае мнгопользовательской машины, когда все люди сидят в одном классе, может не быть никакой идентификации - человек садится, в журнале расписывается, и ему каким-то образом обозначаются права; в случае, если человек присоединяется из сети - там совершенно непонятно что), и в системе должно быть предусмотрено такое понятие, как категории пользователей, для которых алгоритм определения прав доступа для каждой категории свой. Возможно даже, для одних пользователей это будет доступ по заранее заданным правилам, для других - они сами определяют, для третьих - определяет начальник и т.д.

Классическая юних-система носила на себе не реальную вот эту вот политику, а следы её.

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

Разумеется, ни о какой гибкости реализации этих механизмов на том уровне, о котором сказано выше, нельзя говорить. В идеале, группы и права доступа должны как-то моделироваться и задаваться. Например, при третьем уровне доступа правила вычисления прав доступа конкретного пользователя, принадежащего к конкретной группе, могут отличаться разительным образом, для одних ACL, для других - мандаты, для третьих ещё что-то... В юниксе это было сведено до некоторых упрощённых представлений, которые уже не зависят от того, какой у вас ранлевел. А именно, есть файловая система, есть пользователи и группы, у них есть жёсткие алгоритмы вычисления прав доступа одного к Вместо того, к другому, а вместо того, чтобы привязывать возможность делать всё, что угодно, с системой к 1 ранлевелу, это привязано к доверенному субъекту, пользователю, чей идентификатор равен 0. Фактически, классический юникс - очень упрощённая реализация требуемой военщиками трёхуровневой модели доступа. При этом, там уже есть некоторые отклонения, потому что не то, что вы умудрились получить шелл на первои ранлевеле, а то, что вы умудрились зарегистрироваться как рут, определяет, что вы крутой. И вы точно также можете зарегистрироваться как рут на втором или третьем ранлевеле и получить такой же самый уровень доступа.

Так вот, согласно этой архитектуре, действительно было возможно такое, что на первом уровне запускаются отдельные службы, на втором к ним добавляются службы, которые позволяют отличать пользователя от пользователя, и на третьем к ним добавляются службы которые организуют доступ произвольного пользователя из сети, если это нужно, и позволяют отличать пользователя по категории. Но уже в юниксе такого нет. Там устоялась следующая традиция: однопользовательский режим, многопользовательский режим, многопользовательский режим с сетью. Понятно, что сейчас про всё это забыли, реализация соответствующих мандатных прав доступа накладывается в линукс-системы сверху, селинуксом например, и алгоритм запуска процесса в ранлевеле тоже поменялся. Никто не проходит все ранлевелы подряд, а убиваются все одни сервисы, запускаются все вторые, в лучшем случае, те, которые там и там есть, просто не убиваются. Поэтому ранлевелами стали пользоваться как профилями системы с небольшим легаси, чтобы на пятом уровне запускался ещё и графический сервер. Ничего удивительного, что люди, которые родились в те самые поры, когда юних-системы стремительно модифицировались, а про мультикс все забыли, они, когда чего-то пишут, ранлевелами пользуются абы как. Просто знают, что 2,3,4,5 - это ранлевелы, где не-рут. То есть сводят модель к бинарному делению: однопользовательский режим, где один только рут, и многопользовательский режим, где всё. Поэтому на сегодняшний день есть большой бардак в sysvinit.

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

Сведения о ресурсах

CategoryLectures CategoryPspo CategoryMpgu CategoryUneex