|
Размер: 10356
Комментарий:
|
Размер: 10978
Комментарий:
|
| Удаления помечены так. | Добавления помечены так. |
| Строка 3: | Строка 3: |
| Посмотрим чень кратуий пересказ того, что такое урвни вып., более подробно см. учебник. Ур. вып. есть некая абстракция, которая упоминается в конф. фаыле init, inittab. Это такая штука замороченная, довольн старого фрмато, простой смертный там ничего менять не должен, за исключением, рпзве что умолчального уровня выполнения, который значится в полне init-default. | Поговорим немного об уровнях выполнения. Вообще, это некоторая абстракция, упоминаемая в конфигурационном файле для init --- inittab. В inittab редко приходится менять что-либо, за единственным возможным исключением --- в строке с initdefault выставляется уровень выполнения по умолчанию. В inittab задается разделение на уровни выполнения; реально же запускаемые при старте системы службы определяются командой chkconfig. |
| Строка 5: | Строка 5: |
| Там есть ещё мнго всякого интересного, какие ерм, склько консолей, там вообще описание процесса загрузки. | При переходе с одного уровня выполнения на другой система производит следующие действия. Определяется, какие службы должны быть запущены, а какие --- остановлены (по сравнению с наличествующей картиной), после чего выполняется собственно переключение. Администратор системы может переключать систему с одного уровня выполнения на другой, выполняя команду init с единственным параметром --- номером нужного уровня. |
| Строка 7: | Строка 7: |
| В частности, в inittab неск. аз упоминаются урвни выполнения, в частности, дефолтный, и уровни выполнения, и скрипты, которые им соотв. | Уровни выполнения, таким образом, можно, хотя и с некоторой натяжкой, воспринимать как профили работы одной и той же системы. Исторически сложилось так, что уровень 0 соответствует полной остановке системы с выключением, а уровень 6 --- перезагрузке (остановка и загрузка заново, на уровень по умолчанию). Что касается остальных уровней, то по традиции уровень 1 --- это однопользовательский режим работы, уровень 2 --- многопользовательский режим без сети, уровень 3 --- многопользовательский режим с сетью. Поведение системы на других уровнях выполнения не специфицируется, однако считается, что уровень 5 --- это многопользовательский режим с сетью и графическим интерфейсом. В дистрибутивах ПСПО уровень 7 соответствует работе инсталлятора. |
| Строка 9: | Строка 9: |
| Дальнейшее описание лектор откладывает на книжку, упомянет тольк что, так уж сложилось традиц., что переход с ур. вып на ур. вып. зн. прибивание всех прцессов, которые запущены на одном ур, и не должны быть щапущ на другом (в альте это уст. по chkconfig), но некая ид. модель ур. вып. состоит в том, чт прибивает одни службы и запускает другие. | Обратим внимание на то, что таким образом устроенная система уровней выполнения довольно неудобна. Уровни выполнения уже давно не проходятся подряд: не происходит загрузки на первый уровень с переключением на второй, третий и так до нужного. Фактически, разрешен непосредственный переход с любого уровня выполнения на любой другой. Иными словами, само слово "уровень" потеряло в данной схеме свое значение. Почему уровней выполнения (по сути дела --- профилей работы системы) существует столько, сколько сейчас --- вопрос традиции, а не удобства. В BSD-системах, заметим, по сути есть только два уровня выполнения: однопользовательский и штатный. |
| Строка 11: | Строка 11: |
| В действ всё происх. не так, как на самом деле, и как лектору помнится, при переходе с уровня на уровень то ли считается, что их надо подряд прохдить, короче говоря, что скрипты, которые вып. , тлько если служба запущена... в общем есть вещи, которые там что-т усложняют. Короче, когда говорится init уровень, должен быть переход. | Чтобы понять, почему загрузка системы организована именно так, вспомним некоторые факты из истории. Система init была написана примерно очень давно, еще во времена коммерческого UNIX. Создатели UNIX --- Кен Томпсон и Деннис Ритчи --- работали также над ОС MULTICS по заказу военных ведомств. Разделение доступа в MULTICS проходило по довольно хитрым алгоритмам: |
| Строка 13: | Строка 13: |
| Уровни эти 0..6 (7, 8) v;y c натяжкой воспр. как прфили рабо системы. Ист. сложилось, чт ур. 0 --- выключчение, 6 --- перезагрузкаю. Что кас. ост., есть довольно давняя традиция, что 1 --- одноп. режим., 2 --- многоп. без сети, 3 --- одноп. с сетью. 5 часто многоп. с сетью и граф. режимом. Нигде это не станд., но кто-то так решил. | * В некоторое время система могла работать по следующему принципу: во время каждого сеанса доступа к данным есть только один субъект. Понятно, что если субъект только один, то с данными он может делать все, что ему заблагорассудится. Необходимости защищать данные от произвольного доступа, таким образом, нет, а вот от непроизвольного доступа --- есть: если в системе одновременно функционирует несколько процессов, они не должны иметь возможность испортить данные друг друга. |
| Строка 15: | Строка 15: |
| Если приост. и подумать, каке удобство вот в таком, то поймём, что никакого удобства нет. Давным давно ур. не прходятся поряд, давным давно, не происх. переход с пред. на след. Давным давно мжно переход.с с ур. на уровня. Это прсто нек. прфиль. | * При другой схеме функционирования в системе могли работать сразу несколько субъектов одного класса. Эти субъекты составляли "команду" и потому не имели серьезных поражений в правах по сравнению друг с другом. Тем не менее, при такой схеме работал механизм защиты от произвольного доступа --- подобный ACL. |
| Строка 17: | Строка 17: |
| Во-вторых, соверш. неоч., почему этих профилей должно быть 4, а не 10, не 2. В системах BSD есть толь 2 уровня --- системный и штатный. Если нужно длеать что-то, чтобы никто не мешал, то перехдишь в дноп. режим.ю | * Еще более сложная схема соответствовала работе в системе пользователей разных категорий. Условно говоря, подключенные к машине терминалы могли соответствовать пользователям одной категории, а соединения с системой по сети --- пользователям другой категории. Для каждой из таких категорий алгоритм определения прав доступа мог задаваться отдельно. |
| Строка 19: | Строка 19: |
| При этом соверш. неопнятно, зачет это нужно. Дело в том, что когда Кен и Деннис работали над (вы же пнимаете, что init был написан примерно тгда, когда и первое ядро UNIX, а может и раньше). Надо напомнить, что Кен и Деннис в рабочее время работали над ОС multics? где работали военщики, монго теории там реализовано. Есть легенда, что та система была построена, сдана и сущ. в ед. экземпляре. Была история, что деннис назвал юникс так, чтобы посмеяться над юнисм. И дело в ом, что малтикс --- военная система, военные любят разделение не демократичное, а согл. правилам, мандатный доступ (считайте, ACL, только орг. по спец. алгоритмам). С этой т. з., когда мы опр. дступ субъектов системы к обыъектам, важно разделдение категорий субъектов. Может быть так, чт при каждом сеянсе доступа к данным есть тлько один субъект. Вообще говря, если есть один субъект, то что, н мжет там делать --- его проблемы. Поэому нет необх. защищать данные от призв. доступа. След. урвень, на котором мы олжны гораздо больш. безоп. развдить --- когда есть меного субъектв дного класса. Считается , что у них нет серъёзных пораж в правах, у них естб один. уровень доступа, но было бы непл. защитить их данные от доступа друг друга, если они этго захотят или если так требует устав. Мы должны выраб. механизм от произв. дступа и на этом ост. Есть правила, ктор. уст. способ доступа, и на этом ост. | Классическая UNIX-система содержала следы этой запутанной политики: |
| Строка 21: | Строка 21: |
| Ещё блее слжная ситуация наст., кгда в сист. работают пльз. разных категорий. В ситуации, когда к компьютеру может подкл. кто угодно, т мы явно имеем ситуацию другую --- мы имеем небх. разделения польз. по категориям. Что при этом присх. с сист. --- усл. мехнизм идентификации (в случае мнгоп. машины), и в машине должен быть предусмотрен механизм задания правил доступа. | * Первый уровень доступа частично соответствовал однопользовательскому режиму: это монопольный доступ к консоли машины. |
| Строка 23: | Строка 23: |
| Классич. юних-система носила не реальную политику, а следы её. И первый уровень дост. соотв. одноп. режиму --- то есть человек запускает систему и приоизв действ. с систеомй, это похоже на первой ур. по этой классиф. | * Второй уровень доступа частично соответствовал многопользовательскому режиму: сидящие за терминалами пользователи образовывали "команду". |
| Строка 25: | Строка 25: |
| 2 ур. доступа --- соотв. 2 ур. доступа по этой классиф (кгда все субъекту сотв этой категории) | * Третий уровень доступа частично соответствовал подключению машины к сети. |
| Строка 27: | Строка 27: |
| 3 ур. доступа --- когда машина дост. п сети. | Разумеется, ни о какой гибкости реализации этих механизмов речи не шло. В идеале, права доступа на третьем уровне могли различаться даже алгоритмами определения: для одной категории --- ACL, для другой --- мандаты и пр. В UNIX это было сведено к некоторым упрощенным представлениям, уже не зависящим от уровня выполнения: есть файловая система, пользователи и группы, причем вычисление прав доступа определяется в соответствии с жестким, заранее заданным алгоритмом. Возможность делать с системой все, что угодно, была привязана не к уровню выполнения, а к доверенному субъекту --- пользователю с идентификатором 0. |
| Строка 29: | Строка 29: |
| Никакой ... Например, при третьем ур. правила выч. доступа могут отличаться разит. образом, и в юниксе это было сведено до минимума, и не зависит от того, какой ранлевел. Вместо того, чтобы привязывать возм. делать всё, что можно с сист., привязывать к 1 ранлевелу, это привязан к 0. Факт., классич. юникс --- чень упрощ. реализ. требуемой военщиками трёхур. доступа. И там уже некое откл. от той модели Так вот, согл. этой архитектуре, возм. такое, чт на 1 зап. осн. службы, на вторм зап. службы, которые позв. тл. плоьз., и далее службы которые включают сеть и мандаты. Понятно, что сейчас про всё это забыли, и дп. алгоритмы прав накладываеются селинуксом и так далее, и ранлевелы не проходятся подряд, а просто выполняется дифф. Ничего удивительного, что люди, которые родились в те самые пры, кгда юних-системы стрем. модиф, а про мультикс забыли, они ранлевелами польз. абы как. То есть своядт модель к бин. делению.э Поэтому на сегодняшнему моменту бльшой бардак в этом. Вот такой рассказ о тм, что представляли собой когда-т уровни вып., про них самих расск. в книжке. |
Заметим, что такая архитектура позволяла организовать следующую схему. На первом уровне можно было запускать некоторые "системные" службы, на втором --- добавлять к ним службы, различающие пользователей, на третьем --- службы, организующие доступ пользователей из сети. Так устоялась традиция разделения на однопользовательский режим, многопользовательский режим и многопользовательский режим с сетью, которые соответствуют 1-му, 2-му и 3-му уровням выполнения. В настоящее время описанная модель потеряла практический смысл (реализация различных схем определения прав доступа может определяться, к примеру, подсистемой SELinux), а потому соответствующая схема работы (System V init) воспринимается как legacy. |
| Строка 47: | Строка 37: |
| || 0 || 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 |
|
|