|
Размер: 20275
Комментарий:
|
Размер: 10978
Комментарий:
|
| Удаления помечены так. | Добавления помечены так. |
| Строка 2: | Строка 2: |
| Здесь приведён очень краткий пересказ того, что такое урвни выполнения, более подробно см. учебник. Уровни выполнения есть некая абстракция, которая упоминается в конфигурационном файле init, inittab. Это замороченная штука, довольно старого фрмата, простой смертный там ничего менять не должен, за исключением уровня выполнения по умолчанию, который указывается в строчке init-default. Там есть ещё мнго всякого интересного, там описывается, какие терминалы, склько консолей... в общем, описание процесса init в самом старте системы. В частности, в inittab несколько раз упоминается понятие "уровень выполнения", в частности, используемый по умолчанию (вышеупомянутый init-default), и уровни выполнения с шелльными скриптами, которые им соответствуют. Дальнейшее описание лектор откладывает на книжку, упомянет только, что, так уж сложилось по традиции, что переход с уровня выполнения на уровень выполнения означает прибивание всех служб, которые запущены на одном уровне, но не должны запускаться на другом (в альте это регулируется командой chkconfig). | |
| Строка 4: | Строка 3: |
| В действительности всё происходит не так, как на самом деле, и как лектору помнится, при переходе с уровня на уровень вроде бы считается, что их надо подряд прохдить, скрипты, которые убивают службы, делают это только если соответствующие службы запущены... в общем, есть какая-то доделка, которая весь этот алгоритм усложняет. Короче, когда говорится init уровень, система должна на этот уровень перейти и проделать соответствующие действия, что-то подняв и что-то восстановив. | Поговорим немного об уровнях выполнения. Вообще, это некоторая абстракция, упоминаемая в конфигурационном файле для init --- inittab. В 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 уровня - однопользовательский, то есть тот, где ничего нет, только шелл да консоль, и штатный. Предполагается, что если нужно делать что-то так, чтобы никто не беспокоил, то переходишь в однопользовательский режим и всё делаешь. | Уровни выполнения, таким образом, можно, хотя и с некоторой натяжкой, воспринимать как профили работы одной и той же системы. Исторически сложилось так, что уровень 0 соответствует полной остановке системы с выключением, а уровень 6 --- перезагрузке (остановка и загрузка заново, на уровень по умолчанию). Что касается остальных уровней, то по традиции уровень 1 --- это однопользовательский режим работы, уровень 2 --- многопользовательский режим без сети, уровень 3 --- многопользовательский режим с сетью. Поведение системы на других уровнях выполнения не специфицируется, однако считается, что уровень 5 --- это многопользовательский режим с сетью и графическим интерфейсом. В дистрибутивах ПСПО уровень 7 соответствует работе инсталлятора. |
| Строка 10: | Строка 9: |
| При этом совершенно непонятно, зачем это нужно. Дело в том, что init был написан примерно тогда, когда и первое ядро UNIX, а может и раньше. Надо напомнить, что Кен и Деннис в рабочее время работали над ОС multics, где работали военщики, где много теории было реализовано. Есть легенда, что эта система была доведена до рабочего состояния, сдана заказчику и существовала в единственном экземпляре, так как была построена по нетиражируемым технологиям. Была история, что деннис назвал юникс так, чтобы поглумиться над названием multics. Дело даже не в этом, а в том, что ОС малтикс была написана по заказу военных, которые любят разделение доступа не демократичное, а сообразно правилам, в российской терминологии - мандатный доступ (нечто вроде ACL, только организованное по специальным алгоритмам). С этой точки зрения, когда мы определяем права доступа субъектов системы к объектам, важно разделдение в категорях самих субъектов. * Может быть так, что система работает так, что при каждом сеансе доступа к данным есть только один субъект. С точки зрения секретности, если есть один субъект, то что бы он ни делал с данными, это его проблеммы. Поэому нет необходимости защищать данные от произвольного доступа. От непроизвольного стоит - когда у нас есть много процесссов, неплохо, чтобы они не портили свои данные случайно. * Следующий уровень, на котором мы должны гораздо больше безопасности разводить - когда есть много субъектов одного класса. Считается, что у них нет серъёзных поражений в правах, условно говоря, это - некая команда, они имеют одинаковые уровни доступа к документам и т.д., но было бы неплохо защитить их данные от доступа друг друга, если они этого не хотят или если это запрещено уставом. Мы должны выработать механизм защиты от произвольного доступа и на этом остановиться. То есть, есть правило, определяющее, как организуется защита от произвольного доступа, в случае юникса вы руками выставляете права даоступа на свои файлы, в случае системы, где это регулируется сверху, будет некая матрица, по которой это будет видно. * Ещё более сложная ситуация наступает, когда в системе работают пользователи разных категорий, то есть такие, алгоритм определения прав доступа которых к объектам системы для каждой группы пользователей различен. Есть серьёзные пользователи, есть левые пользователи и т.д. То есть, в ситуации, когда к компьютеру присоединено двадцать терминалов, на каждом из которых сидит по одному человеку, это пользователи одной категории, а если к компьютеру может присоединиться кто угодно, мы явно имеем другую ситуацию - мы имеем небходимость разделения пользователей по категориям. Некоторые, которые подтвердили свою высокую категорию доступа, имеют одни права, некоторые - другие... Что при этом присходит с системой? Усложняется мехнизм идентификации (в случае мнгопользовательской машины, когда все люди сидят в одном классе, может не быть никакой идентификации - человек садится, в журнале расписывается, и ему каким-то образом обозначаются права; в случае, если человек присоединяется из сети - там совершенно непонятно что), и в системе должно быть предусмотрено такое понятие, как категории пользователей, для которых алгоритм определения прав доступа для каждой категории свой. Возможно даже, для одних пользователей это будет доступ по заранее заданным правилам, для других - они сами определяют, для третьих - определяет начальник и т.д. |
Обратим внимание на то, что таким образом устроенная система уровней выполнения довольно неудобна. Уровни выполнения уже давно не проходятся подряд: не происходит загрузки на первый уровень с переключением на второй, третий и так до нужного. Фактически, разрешен непосредственный переход с любого уровня выполнения на любой другой. Иными словами, само слово "уровень" потеряло в данной схеме свое значение. Почему уровней выполнения (по сути дела --- профилей работы системы) существует столько, сколько сейчас --- вопрос традиции, а не удобства. В BSD-системах, заметим, по сути есть только два уровня выполнения: однопользовательский и штатный. |
| Строка 15: | Строка 11: |
| Классическая юних-система носила на себе не реальную вот эту вот политику, а следы её. * Первый уровень доступа частично соответствует однопользовательскому режиму - то есть человек имеет доступ к консоли и запускает её таким образом, что он только один производит какие-то действия над систеомй, это похоже на первой уровень доступа по этой классификации. * Когда машина многопользовательская, то есть, она стоит в углу, к ней присоединены терминалы, за которыми сидит личный состав, но все эти люди имеют одинаковую категорию, это более или менее соответствует второму уровню доступа по этой классификации (когда все субъекты в системе принадлежат одной категории). * Наконец, когда машина подключена к сети, это соответствует третьему уровню доступа. |
Чтобы понять, почему загрузка системы организована именно так, вспомним некоторые факты из истории. Система init была написана примерно очень давно, еще во времена коммерческого UNIX. Создатели UNIX --- Кен Томпсон и Деннис Ритчи --- работали также над ОС MULTICS по заказу военных ведомств. Разделение доступа в MULTICS проходило по довольно хитрым алгоритмам: |
| Строка 20: | Строка 13: |
| Разумеется, ни о какой гибкости реализации этих механизмов на том уровне, о котором сказано выше, нельзя говорить. В идеале, группы и права доступа должны как-то моделироваться и задаваться. Например, при третьем уровне доступа правила вычисления прав доступа конкретного пользователя, принадежащего к конкретной группе, могут отличаться разительным образом, для одних ACL, для других - мандаты, для третьих ещё что-то... В юниксе это было сведено до некоторых упрощённых представлений, которые уже не зависят от того, какой у вас ранлевел. А именно, есть файловая система, есть пользователи и группы, у них есть жёсткие алгоритмы вычисления прав доступа одного к Вместо того, к другому, а вместо того, чтобы привязывать возможность делать всё, что угодно, с системой к 1 ранлевелу, это привязано к доверенному субъекту, пользователю, чей идентификатор равен 0. Фактически, классический юникс - очень упрощённая реализация требуемой военщиками трёхуровневой модели доступа. При этом, там уже есть некоторые отклонения, потому что не то, что вы умудрились получить шелл на первои ранлевеле, а то, что вы умудрились зарегистрироваться как рут, определяет, что вы крутой. И вы точно также можете зарегистрироваться как рут на втором или третьем ранлевеле и получить такой же самый уровень доступа. | * В некоторое время система могла работать по следующему принципу: во время каждого сеанса доступа к данным есть только один субъект. Понятно, что если субъект только один, то с данными он может делать все, что ему заблагорассудится. Необходимости защищать данные от произвольного доступа, таким образом, нет, а вот от непроизвольного доступа --- есть: если в системе одновременно функционирует несколько процессов, они не должны иметь возможность испортить данные друг друга. |
| Строка 22: | Строка 15: |
| Так вот, согласно этой архитектуре, действительно было возможно такое, что на первом уровне запускаются отдельные службы, на втором к ним добавляются службы, которые позволяют отличать пользователя от пользователя, и на третьем к ним добавляются службы которые организуют доступ произвольного пользователя из сети, если это нужно, и позволяют отличать пользователя по категории. Но уже в юниксе такого нет. Там устоялась следующая традиция: однопользовательский режим, многопользовательский режим, многопользовательский режим с сетью. Понятно, что сейчас про всё это забыли, реализация соответствующих мандатных прав доступа накладывается в линукс-системы сверху, селинуксом например, и алгоритм запуска процесса в ранлевеле тоже поменялся. Никто не проходит все ранлевелы подряд, а убиваются все одни сервисы, запускаются все вторые, в лучшем случае, те, которые там и там есть, просто не убиваются. Поэтому ранлевелами стали пользоваться как профилями системы с небольшим легаси, чтобы на пятом уровне запускался ещё и графический сервер. Ничего удивительного, что люди, которые родились в те самые поры, когда юних-системы стремительно модифицировались, а про мультикс все забыли, они, когда чего-то пишут, ранлевелами пользуются абы как. Просто знают, что 2,3,4,5 - это ранлевелы, где не-рут. То есть сводят модель к бинарному делению: однопользовательский режим, где один только рут, и многопользовательский режим, где всё. Поэтому на сегодняшний день есть большой бардак в sysvinit. | * При другой схеме функционирования в системе могли работать сразу несколько субъектов одного класса. Эти субъекты составляли "команду" и потому не имели серьезных поражений в правах по сравнению друг с другом. Тем не менее, при такой схеме работал механизм защиты от произвольного доступа --- подобный ACL. |
| Строка 24: | Строка 17: |
| Вот такой рассказ о том, что представляли собой когда-то уровни выполнения и во что они превратились, а как они работают, рассказано в книжке. | * Еще более сложная схема соответствовала работе в системе пользователей разных категорий. Условно говоря, подключенные к машине терминалы могли соответствовать пользователям одной категории, а соединения с системой по сети --- пользователям другой категории. Для каждой из таких категорий алгоритм определения прав доступа мог задаваться отдельно. Классическая UNIX-система содержала следы этой запутанной политики: * Первый уровень доступа частично соответствовал однопользовательскому режиму: это монопольный доступ к консоли машины. * Второй уровень доступа частично соответствовал многопользовательскому режиму: сидящие за терминалами пользователи образовывали "команду". * Третий уровень доступа частично соответствовал подключению машины к сети. Разумеется, ни о какой гибкости реализации этих механизмов речи не шло. В идеале, права доступа на третьем уровне могли различаться даже алгоритмами определения: для одной категории --- ACL, для другой --- мандаты и пр. В UNIX это было сведено к некоторым упрощенным представлениям, уже не зависящим от уровня выполнения: есть файловая система, пользователи и группы, причем вычисление прав доступа определяется в соответствии с жестким, заранее заданным алгоритмом. Возможность делать с системой все, что угодно, была привязана не к уровню выполнения, а к доверенному субъекту --- пользователю с идентификатором 0. Заметим, что такая архитектура позволяла организовать следующую схему. На первом уровне можно было запускать некоторые "системные" службы, на втором --- добавлять к ним службы, различающие пользователей, на третьем --- службы, организующие доступ пользователей из сети. Так устоялась традиция разделения на однопользовательский режим, многопользовательский режим и многопользовательский режим с сетью, которые соответствуют 1-му, 2-му и 3-му уровням выполнения. В настоящее время описанная модель потеряла практический смысл (реализация различных схем определения прав доступа может определяться, к примеру, подсистемой SELinux), а потому соответствующая схема работы (System V init) воспринимается как legacy. |
| Строка 32: | Строка 37: |
| || 20 || 1 || 1 || 1 || || 1 || ConstantinYershow, DmitryChistikov, VsevolodKrishchenko || || || | || 35 || 1 || 1 || 1 || || 1 || ConstantinYershow, DmitryChistikov, VsevolodKrishchenko || || || |
Уровни выполнения
Поговорим немного об уровнях выполнения. Вообще, это некоторая абстракция, упоминаемая в конфигурационном файле для init --- inittab. В inittab редко приходится менять что-либо, за единственным возможным исключением --- в строке с initdefault выставляется уровень выполнения по умолчанию. В inittab задается разделение на уровни выполнения; реально же запускаемые при старте системы службы определяются командой chkconfig.
При переходе с одного уровня выполнения на другой система производит следующие действия. Определяется, какие службы должны быть запущены, а какие --- остановлены (по сравнению с наличествующей картиной), после чего выполняется собственно переключение. Администратор системы может переключать систему с одного уровня выполнения на другой, выполняя команду init с единственным параметром --- номером нужного уровня.
Уровни выполнения, таким образом, можно, хотя и с некоторой натяжкой, воспринимать как профили работы одной и той же системы. Исторически сложилось так, что уровень 0 соответствует полной остановке системы с выключением, а уровень 6 --- перезагрузке (остановка и загрузка заново, на уровень по умолчанию). Что касается остальных уровней, то по традиции уровень 1 --- это однопользовательский режим работы, уровень 2 --- многопользовательский режим без сети, уровень 3 --- многопользовательский режим с сетью. Поведение системы на других уровнях выполнения не специфицируется, однако считается, что уровень 5 --- это многопользовательский режим с сетью и графическим интерфейсом. В дистрибутивах ПСПО уровень 7 соответствует работе инсталлятора.
Обратим внимание на то, что таким образом устроенная система уровней выполнения довольно неудобна. Уровни выполнения уже давно не проходятся подряд: не происходит загрузки на первый уровень с переключением на второй, третий и так до нужного. Фактически, разрешен непосредственный переход с любого уровня выполнения на любой другой. Иными словами, само слово "уровень" потеряло в данной схеме свое значение. Почему уровней выполнения (по сути дела --- профилей работы системы) существует столько, сколько сейчас --- вопрос традиции, а не удобства. В BSD-системах, заметим, по сути есть только два уровня выполнения: однопользовательский и штатный.
Чтобы понять, почему загрузка системы организована именно так, вспомним некоторые факты из истории. Система init была написана примерно очень давно, еще во времена коммерческого UNIX. Создатели UNIX --- Кен Томпсон и Деннис Ритчи --- работали также над ОС MULTICS по заказу военных ведомств. Разделение доступа в MULTICS проходило по довольно хитрым алгоритмам:
- В некоторое время система могла работать по следующему принципу: во время каждого сеанса доступа к данным есть только один субъект. Понятно, что если субъект только один, то с данными он может делать все, что ему заблагорассудится. Необходимости защищать данные от произвольного доступа, таким образом, нет, а вот от непроизвольного доступа --- есть: если в системе одновременно функционирует несколько процессов, они не должны иметь возможность испортить данные друг друга.
- При другой схеме функционирования в системе могли работать сразу несколько субъектов одного класса. Эти субъекты составляли "команду" и потому не имели серьезных поражений в правах по сравнению друг с другом. Тем не менее, при такой схеме работал механизм защиты от произвольного доступа --- подобный ACL.
- Еще более сложная схема соответствовала работе в системе пользователей разных категорий. Условно говоря, подключенные к машине терминалы могли соответствовать пользователям одной категории, а соединения с системой по сети --- пользователям другой категории. Для каждой из таких категорий алгоритм определения прав доступа мог задаваться отдельно.
Классическая UNIX-система содержала следы этой запутанной политики:
- Первый уровень доступа частично соответствовал однопользовательскому режиму: это монопольный доступ к консоли машины.
- Второй уровень доступа частично соответствовал многопользовательскому режиму: сидящие за терминалами пользователи образовывали "команду".
- Третий уровень доступа частично соответствовал подключению машины к сети.
Разумеется, ни о какой гибкости реализации этих механизмов речи не шло. В идеале, права доступа на третьем уровне могли различаться даже алгоритмами определения: для одной категории --- ACL, для другой --- мандаты и пр. В UNIX это было сведено к некоторым упрощенным представлениям, уже не зависящим от уровня выполнения: есть файловая система, пользователи и группы, причем вычисление прав доступа определяется в соответствии с жестким, заранее заданным алгоритмом. Возможность делать с системой все, что угодно, была привязана не к уровню выполнения, а к доверенному субъекту --- пользователю с идентификатором 0.
Заметим, что такая архитектура позволяла организовать следующую схему. На первом уровне можно было запускать некоторые "системные" службы, на втором --- добавлять к ним службы, различающие пользователей, на третьем --- службы, организующие доступ пользователей из сети. Так устоялась традиция разделения на однопользовательский режим, многопользовательский режим и многопользовательский режим с сетью, которые соответствуют 1-му, 2-му и 3-му уровням выполнения. В настоящее время описанная модель потеряла практический смысл (реализация различных схем определения прав доступа может определяться, к примеру, подсистемой SELinux), а потому соответствующая схема работы (System V init) воспринимается как legacy.
Сведения о ресурсах
Готовность (%) |
Продолжительность (ак. ч.) |
Подготовка (календ. ч.) |
Полный текст (раб. д.) |
Предварительные знания |
Level |
Maintainer |
Start date |
End date |
35 |
1 |
1 |
1 |
|
1 |
|
|