Различия между версиями 2 и 4 (по 2 версиям)
Версия 2 от 2008-08-06 11:24:14
Размер: 20275
Редактор: ConstantinYershow
Комментарий:
Версия 4 от 2008-08-08 12:34:38
Размер: 11977
Редактор: DmitryChistikov
Комментарий:
Удаления помечены так. Добавления помечены так.
Строка 2: Строка 2:
Здесь приведён очень краткий пересказ того, что такое урвни выполнения, более подробно см. учебник. Уровни выполнения есть некая абстракция, которая упоминается в конфигурационном файле init, inittab. Это замороченная штука, довольно старого фрмата, простой смертный там ничего менять не должен, за исключением уровня выполнения по умолчанию, который указывается в строчке init-default. Там есть ещё мнго всякого интересного, там описывается, какие терминалы, склько консолей... в общем, описание процесса init в самом старте системы. В частности, в inittab несколько раз упоминается понятие "уровень выполнения", в частности, используемый по умолчанию (вышеупомянутый init-default), и уровни выполнения с шелльными скриптами, которые им соответствуют. Дальнейшее описание лектор откладывает на книжку, упомянет только, что, так уж сложилось по традиции, что переход с уровня выполнения на уровень выполнения означает прибивание всех служб, которые запущены на одном уровне, но не должны запускаться на другом (в альте это регулируется командой chkconfig).
Строка 4: Строка 3:
В действительности всё происходит не так, как на самом деле, и как лектору помнится, при переходе с уровня на уровень вроде бы считается, что их надо подряд прохдить, скрипты, которые убивают службы, делают это только если соответствующие службы запущены... в общем, есть какая-то доделка, которая весь этот алгоритм усложняет. Короче, когда говорится init уровень, система должна на этот уровень перейти и проделать соответствующие действия, что-то подняв и что-то восстановив. Поговорим немного об уровнях выполнения. Уровень выполнения представляет собой специальную абстракцию, упоминаемую в /etc/inittab --- конфигурационном файле для первого запускаемого при загрузке системы процесса (он носит имя init). Изменять файл inittab приходится весьма нечасто, причем большинство изменений касаются только строки с параметром initdefault: в ней задается уровень выполнения по умолчанию. При этом можно сказать, что файл inittab лишь создает разделение на уровни выполнения: за конфигурацию набора запускаемых служб отвечает (в дистрибутивах ПСПО и многих других) утилита chkconfig.
Строка 6: Строка 5:
Уровни эти 0..6 (7, 8) можно c натяжкой воспринимать как прфили работы одной и той же системы. Исторически сложилось, что уровень 0 - полная остановка системы с выключением, если это возможно, 6 - перезагрузка системы (остановка и загрузка заново на уровень по умолчанию). Что касается всех остальных уровней, есть довольно давняя традиция, что уровень 1 - однопользовательский режим, 2 - многопользовательский режим без сети, 3 - многопользовательский режим с сетью. Остальное никак не специфицированно, хотя традиционно считается, что уровень 5 - это многопользовательский режим с сетью и графическим интерфейсом. Кажется, седьмой уровень - это уровень инсталлятора. Пятый и седьмой уровень нигде не стандартизованы, и вообще непонятно, почему так кто-то решил; видимо, для современных систем, где наличествует графика, пятый уровень должен отличаться от третьего. Администратор системы может переключать систему с одного уровня выполнения на другой, выполняя команду init с единственным параметром --- номером нужного уровня. При переходе система определяет, какие службы должны быть запущены, а какие --- остановлены, выполняет необходимые операции и производит собственно переключение.
Строка 8: Строка 7:
Если приостановиться и подумать, зачем так устроено и какое в этом удобство, мы поймём, что никакого удобства в этом нет. Давным-давно уровни не проходятся поряд, давным давно не бывает такого, что наша система сначала входит в первый уровень и запускает службы, необходимые на первом уровне, потом переходит с первого на второй уровень, дозапусковывает службы, необходимые на втором уровне и т.д. В реальности делается так: убиваются все службы, которые должны убиться, а потом они запускаются заново, или убивается некоторая высчитанная разница... Как-то так. И можно переходить с любого уровня на любой. То есть, фактически, никакого понятия "уровень" уже нет. Это просто некий профиль - однопользовательский, многопользовательский там, многопользовательский с сетью... Совершенно неочевидно, почему этих профилей должно быть 4, а не 10, не 2. В системах BSD есть только 2 уровня - однопользовательский, то есть тот, где ничего нет, только шелл да консоль, и штатный. Предполагается, что если нужно делать что-то так, чтобы никто не беспокоил, то переходишь в однопользовательский режим и всё делаешь. Сами уровни выполнения можно, хотя и с некоторой натяжкой, воспринимать как профили работы одной и той же системы. Тем не менее, к уровням выполнения причисляют также некоторые специальные действия:
Строка 10: Строка 9:
При этом совершенно непонятно, зачем это нужно. Дело в том, что init был написан примерно тогда, когда и первое ядро UNIX, а может и раньше. Надо напомнить, что Кен и Деннис в рабочее время работали над ОС multics, где работали военщики, где много теории было реализовано. Есть легенда, что эта система была доведена до рабочего состояния, сдана заказчику и существовала в единственном экземпляре, так как была построена по нетиражируемым технологиям. Была история, что деннис назвал юникс так, чтобы поглумиться над названием multics. Дело даже не в этом, а в том, что ОС малтикс была написана по заказу военных, которые любят разделение доступа не демократичное, а сообразно правилам, в российской терминологии - мандатный доступ (нечто вроде ACL, только организованное по специальным алгоритмам). С этой точки зрения, когда мы определяем права доступа субъектов системы к объектам, важно разделдение в категорях самих субъектов.
 * Может быть так, что система работает так, что при каждом сеансе доступа к данным есть только один субъект. С точки зрения секретности, если есть один субъект, то что бы он ни делал с данными, это его проблеммы. Поэому нет необходимости защищать данные от произвольного доступа. От непроизвольного стоит - когда у нас есть много процесссов, неплохо, чтобы они не портили свои данные случайно.
 * Следующий уровень, на котором мы должны гораздо больше безопасности разводить - когда есть много субъектов одного класса. Считается, что у них нет серъёзных поражений в правах, условно говоря, это - некая команда, они имеют одинаковые уровни доступа к документам и т.д., но было бы неплохо защитить их данные от доступа друг друга, если они этого не хотят или если это запрещено уставом. Мы должны выработать механизм защиты от произвольного доступа и на этом остановиться. То есть, есть правило, определяющее, как организуется защита от произвольного доступа, в случае юникса вы руками выставляете права даоступа на свои файлы, в случае системы, где это регулируется сверху, будет некая матрица, по которой это будет видно.
 * Ещё более сложная ситуация наступает, когда в системе работают пользователи разных категорий, то есть такие, алгоритм определения прав доступа которых к объектам системы для каждой группы пользователей различен. Есть серьёзные пользователи, есть левые пользователи и т.д. То есть, в ситуации, когда к компьютеру присоединено двадцать терминалов, на каждом из которых сидит по одному человеку, это пользователи одной категории, а если к компьютеру может присоединиться кто угодно, мы явно имеем другую ситуацию - мы имеем небходимость разделения пользователей по категориям. Некоторые, которые подтвердили свою высокую категорию доступа, имеют одни права, некоторые - другие... Что при этом присходит с системой? Усложняется мехнизм идентификации (в случае мнгопользовательской машины, когда все люди сидят в одном классе, может не быть никакой идентификации - человек садится, в журнале расписывается, и ему каким-то образом обозначаются права; в случае, если человек присоединяется из сети - там совершенно непонятно что), и в системе должно быть предусмотрено такое понятие, как категории пользователей, для которых алгоритм определения прав доступа для каждой категории свой. Возможно даже, для одних пользователей это будет доступ по заранее заданным правилам, для других - они сами определяют, для третьих - определяет начальник и т.д.
 * уровень 0 --- полная остановка системы с выключением (если это возможно);
 * уровень 6 --- перезагрузка, то есть остановка и загрузка заново (на уровень по умолчанию).
Строка 15: Строка 12:
Классическая юних-система носила на себе не реальную вот эту вот политику, а следы её.
 * Первый уровень доступа частично соответствует однопользовательскому режиму - то есть человек имеет доступ к консоли и запускает её таким образом, что он только один производит какие-то действия над систеомй, это похоже на первой уровень доступа по этой классификации.
 * Когда машина многопользовательская, то есть, она стоит в углу, к ней присоединены терминалы, за которыми сидит личный состав, но все эти люди имеют одинаковую категорию, это более или менее соответствует второму уровню доступа по этой классификации (когда все субъекты в системе принадлежат одной категории).
 * Наконец, когда машина подключена к сети, это соответствует третьему уровню доступа.
Что касается других уровней, то чаще всего они используются так:
Строка 20: Строка 14:
Разумеется, ни о какой гибкости реализации этих механизмов на том уровне, о котором сказано выше, нельзя говорить. В идеале, группы и права доступа должны как-то моделироваться и задаваться. Например, при третьем уровне доступа правила вычисления прав доступа конкретного пользователя, принадежащего к конкретной группе, могут отличаться разительным образом, для одних ACL, для других - мандаты, для третьих ещё что-то... В юниксе это было сведено до некоторых упрощённых представлений, которые уже не зависят от того, какой у вас ранлевел. А именно, есть файловая система, есть пользователи и группы, у них есть жёсткие алгоритмы вычисления прав доступа одного к Вместо того, к другому, а вместо того, чтобы привязывать возможность делать всё, что угодно, с системой к 1 ранлевелу, это привязано к доверенному субъекту, пользователю, чей идентификатор равен 0. Фактически, классический юникс - очень упрощённая реализация требуемой военщиками трёхуровневой модели доступа. При этом, там уже есть некоторые отклонения, потому что не то, что вы умудрились получить шелл на первои ранлевеле, а то, что вы умудрились зарегистрироваться как рут, определяет, что вы крутой. И вы точно также можете зарегистрироваться как рут на втором или третьем ранлевеле и получить такой же самый уровень доступа.  * уровень 1 --- однопользовательский режим работы;
 * уровень 2 --- многопользовательский режим без сети;
 * уровень 3 --- многопользовательский режим с сетью.
Строка 22: Строка 18:
Так вот, согласно этой архитектуре, действительно было возможно такое, что на первом уровне запускаются отдельные службы, на втором к ним добавляются службы, которые позволяют отличать пользователя от пользователя, и на третьем к ним добавляются службы которые организуют доступ произвольного пользователя из сети, если это нужно, и позволяют отличать пользователя по категории. Но уже в юниксе такого нет. Там устоялась следующая традиция: однопользовательский режим, многопользовательский режим, многопользовательский режим с сетью. Понятно, что сейчас про всё это забыли, реализация соответствующих мандатных прав доступа накладывается в линукс-системы сверху, селинуксом например, и алгоритм запуска процесса в ранлевеле тоже поменялся. Никто не проходит все ранлевелы подряд, а убиваются все одни сервисы, запускаются все вторые, в лучшем случае, те, которые там и там есть, просто не убиваются. Поэтому ранлевелами стали пользоваться как профилями системы с небольшим легаси, чтобы на пятом уровне запускался ещё и графический сервер. Ничего удивительного, что люди, которые родились в те самые поры, когда юних-системы стремительно модифицировались, а про мультикс все забыли, они, когда чего-то пишут, ранлевелами пользуются абы как. Просто знают, что 2,3,4,5 - это ранлевелы, где не-рут. То есть сводят модель к бинарному делению: однопользовательский режим, где один только рут, и многопользовательский режим, где всё. Поэтому на сегодняшний день есть большой бардак в sysvinit. Списка всех уровней это, однако, не исчерпывает. Поведение системы на оставшихся уровнях выполнения устоялось еще хуже, хотя можно отметить используемое еще одно соглашение, используемое в большинстве систем:
Строка 24: Строка 20:
Вот такой рассказ о том, что представляли собой когда-то уровни выполнения и во что они превратились, а как они работают, рассказано в книжке.  * уровень 5 --- многопользовательский режим с сетью и графическим интерфейсом.

Отметим, что в дистрибутивах ПСПО дополнительно выполняется еще одно правило:

 * уровень 7 --- работа инсталлятора.

Обратим внимание на то, что организованная таким способом система довольно неудобна. Уровни выполнения уже давно не проходятся подряд: не происходит загрузки на первый уровень с переключением на второй, третий и далее до нужного. Фактически, разрешен непосредственный переход с любого уровня выполнения на любой другой --- иными словами, само слово "уровень" потеряло в данной схеме свое значение. Почему уровней выполнения (по сути дела --- профилей работы системы) существует столько, сколько сейчас --- вопрос традиции, а не удобства. В BSD-системах при этом существуют (по сути дела) только два уровня выполнения: однопользовательский и штатный.

Чтобы понять, почему загрузка системы организована именно так, вспомним некоторые факты из истории. Существующая система инициализации, называемая также System V init, была написана очень давно, еще во времена коммерческого UNIX. Создатели UNIX --- Кен Томпсон и Деннис Ритчи --- еще ранее работали над операционной системой MULTICS, спроектированной в соответствии с заказом военных ведомств. В ОС MULTICS существовала следующая хитрая схема разделения на "уровни доступа":

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

 * При втором уровне доступа в системе могли работать сразу несколько субъектов одного класса. Эти субъекты составляли "команду" и потому не имели серьезных поражений в правах по сравнению друг с другом. Тем не менее, при такой схеме работал механизм защиты от произвольного доступа, представляющий по сути дела Access Control List (ACL).

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

Классическая UNIX-система содержала следы этой запутанной политики:

 * Первый уровень доступа частично соответствовал однопользовательскому режиму, который давал монопольный доступ к консоли машины.

 * Второй уровень доступа частично соответствовал многопользовательскому режиму: сидящие за терминалами пользователи образовывали "команду".

 * Третий уровень доступа частично соответствовал подключению машины к сети.

Различные режимы работы в UNIX были названы уровнями выполнения, причем ни о какой гибкости реализации речи не шло. В ОС MULTICS права доступа на третьем уровне могли различаться даже алгоритмами определения: для одной категории --- ACL, для другой --- мандаты и пр. В UNIX это было сведено к некоторым упрощенным представлениям, уже не зависящим от уровня выполнения: на первое место вышла файловая система, пользователи и группы, причем вычисление прав доступа стало определяться в соответствии с жестким, заранее заданным алгоритмом. Возможность делать с системой все, что угодно, была привязана не к уровню выполнения, а к доверенному субъекту --- пользователю с идентификатором 0.

Заметим, что такая архитектура позволяла организовать следующую схему. На первом уровне можно было запускать некоторые "системные" службы, на втором --- добавлять к ним службы, различающие пользователей, на третьем --- службы, организующие доступ пользователей из сети. Так устоялась традиция разделения на однопользовательский режим, многопользовательский режим и многопользовательский режим с сетью, которые соответствуют 1-му, 2-му и 3-му уровням выполнения. В настоящее время описанная модель потеряла практический смысл (реализация различных схем определения прав доступа может определяться, к примеру, подсистемой SELinux), а потому соответствующая часть процесса загрузки (System V init) стала восприниматься как legacy.
Строка 32: Строка 54:
|| 20 || 1 || 1 || 1 || || 1 || ConstantinYershow, DmitryChistikov, VsevolodKrishchenko || || || || 40 || 1 || 1 || 1 || || 1 || ConstantinYershow, DmitryChistikov, VsevolodKrishchenko || || ||

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

Поговорим немного об уровнях выполнения. Уровень выполнения представляет собой специальную абстракцию, упоминаемую в /etc/inittab --- конфигурационном файле для первого запускаемого при загрузке системы процесса (он носит имя init). Изменять файл inittab приходится весьма нечасто, причем большинство изменений касаются только строки с параметром initdefault: в ней задается уровень выполнения по умолчанию. При этом можно сказать, что файл inittab лишь создает разделение на уровни выполнения: за конфигурацию набора запускаемых служб отвечает (в дистрибутивах ПСПО и многих других) утилита chkconfig.

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

Сами уровни выполнения можно, хотя и с некоторой натяжкой, воспринимать как профили работы одной и той же системы. Тем не менее, к уровням выполнения причисляют также некоторые специальные действия:

  • уровень 0 --- полная остановка системы с выключением (если это возможно);
  • уровень 6 --- перезагрузка, то есть остановка и загрузка заново (на уровень по умолчанию).

Что касается других уровней, то чаще всего они используются так:

  • уровень 1 --- однопользовательский режим работы;
  • уровень 2 --- многопользовательский режим без сети;
  • уровень 3 --- многопользовательский режим с сетью.

Списка всех уровней это, однако, не исчерпывает. Поведение системы на оставшихся уровнях выполнения устоялось еще хуже, хотя можно отметить используемое еще одно соглашение, используемое в большинстве систем:

  • уровень 5 --- многопользовательский режим с сетью и графическим интерфейсом.

Отметим, что в дистрибутивах ПСПО дополнительно выполняется еще одно правило:

  • уровень 7 --- работа инсталлятора.

Обратим внимание на то, что организованная таким способом система довольно неудобна. Уровни выполнения уже давно не проходятся подряд: не происходит загрузки на первый уровень с переключением на второй, третий и далее до нужного. Фактически, разрешен непосредственный переход с любого уровня выполнения на любой другой --- иными словами, само слово "уровень" потеряло в данной схеме свое значение. Почему уровней выполнения (по сути дела --- профилей работы системы) существует столько, сколько сейчас --- вопрос традиции, а не удобства. В BSD-системах при этом существуют (по сути дела) только два уровня выполнения: однопользовательский и штатный.

Чтобы понять, почему загрузка системы организована именно так, вспомним некоторые факты из истории. Существующая система инициализации, называемая также System V init, была написана очень давно, еще во времена коммерческого UNIX. Создатели UNIX --- Кен Томпсон и Деннис Ритчи --- еще ранее работали над операционной системой MULTICS, спроектированной в соответствии с заказом военных ведомств. В ОС MULTICS существовала следующая хитрая схема разделения на "уровни доступа":

  • Первый уровень доступа к системе определялся следующим образом. Каждый сеанс доступа к данным управлялся одним и тем же субъектом --- ясно, что с данными этот субъект мог делать все, что ему заблагорассудится. Необходимости защищать данные от произвольного доступа, таким образом, не было, а от непроизвольного --- была: если в системе одновременно функционировали несколько процессов, они не должны были иметь возможности испортить данные друг друга.
  • При втором уровне доступа в системе могли работать сразу несколько субъектов одного класса. Эти субъекты составляли "команду" и потому не имели серьезных поражений в правах по сравнению друг с другом. Тем не менее, при такой схеме работал механизм защиты от произвольного доступа, представляющий по сути дела Access Control List (ACL).
  • Третий уровень доступа соответствовал работе в системе пользователей разных категорий. Условно говоря, подключенные к машине терминалы могли соответствовать пользователям одной категории, а соединения с системой по сети --- пользователям другой категории. Для каждой из таких категорий алгоритм определения прав доступа мог задаваться отдельно.

Классическая UNIX-система содержала следы этой запутанной политики:

  • Первый уровень доступа частично соответствовал однопользовательскому режиму, который давал монопольный доступ к консоли машины.
  • Второй уровень доступа частично соответствовал многопользовательскому режиму: сидящие за терминалами пользователи образовывали "команду".
  • Третий уровень доступа частично соответствовал подключению машины к сети.

Различные режимы работы в UNIX были названы уровнями выполнения, причем ни о какой гибкости реализации речи не шло. В ОС MULTICS права доступа на третьем уровне могли различаться даже алгоритмами определения: для одной категории --- ACL, для другой --- мандаты и пр. В UNIX это было сведено к некоторым упрощенным представлениям, уже не зависящим от уровня выполнения: на первое место вышла файловая система, пользователи и группы, причем вычисление прав доступа стало определяться в соответствии с жестким, заранее заданным алгоритмом. Возможность делать с системой все, что угодно, была привязана не к уровню выполнения, а к доверенному субъекту --- пользователю с идентификатором 0.

Заметим, что такая архитектура позволяла организовать следующую схему. На первом уровне можно было запускать некоторые "системные" службы, на втором --- добавлять к ним службы, различающие пользователей, на третьем --- службы, организующие доступ пользователей из сети. Так устоялась традиция разделения на однопользовательский режим, многопользовательский режим и многопользовательский режим с сетью, которые соответствуют 1-му, 2-му и 3-му уровням выполнения. В настоящее время описанная модель потеряла практический смысл (реализация различных схем определения прав доступа может определяться, к примеру, подсистемой SELinux), а потому соответствующая часть процесса загрузки (System V init) стала восприниматься как legacy.


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

Готовность (%)

Продолжительность (ак. ч.)

Подготовка (календ. ч.)

Полный текст (раб. д.)

Предварительные знания

Level

Maintainer

Start date

End date

40

1

1

1

1

ConstantinYershow, DmitryChistikov, VsevolodKrishchenko


CategoryLectures CategoryPspo CategoryMpgu CategoryUneex

PspoClasses/080729/01RunLevels (последним исправлял пользователь VsevolodKrishchenko 2008-10-04 11:10:06)