Лекции в ворде (1115146), страница 10
Текст из файла (страница 10)
Сегодня мы начинали разговор о том, что у нас есть системные вызовы и библиотеки ввода/вывода. Еще одно средство, которое позволяет оптимизировать работу системы, - это стандартная библиотека ввода/вывода, связанная с include-файлом stdio.h. Суть концептуального обмена та же самая, что и при организации низкоуровневого ввода/вывода. Разница в том, что, если open() возвращает номер файлового дескриптора, fopen() возвращает указатель на некоторую структуру специального типа FILE. Второе и основное - это библиотека функций. Многие функции сервиса, которые предоставляет эта библиотека, реализуются в пределах вашего адресного пространства. В частности, такой функцией сервиса является еще один уровень буферизации ввода/вывода. Суть его заключается в том, что на ресурсах процесса можно выделить буфер, который будет работать аналогично буферному пулу операционной системы и, который минимизирует обращение вашего процесса к системным вызовам ввода/вывода. Понятно, что эта библиотека ввода/вывода реализуется посредством программы, использующей системные вызовы ввода/вывода. Это означает, что появляется фактор двойной буферизации, хотя это увеличивает ненадежность.
Двойная буферизация, очевидно, вещь полезная. Она позволяет обращаться к чтению или записи через библиотечные функции объемами данных в полблока или в треть блока, и если эти части идут подряд, то система сама за счет буферизации, собирает эти части и вместо нескольких обращений к системному вызову выполняет только одно обращение. Это выгодно. Невыгодно то, что эта буферизация организуется в пределах адресного пространства процесса со всеми вытекающими последствиями (теряется синхронизация по обменам в том случае, если с данным файлом через эту библиотеку работают другие процессы, потому что в теле каждого процесса есть свой буфер, который может аккумулировать эти данные и никакого единообразия, которое есть в рассмотренной нами схеме, не получается). Тем не менее, стандартная библиотека ввода/вывода есть удобный инструмент; она имеет также средства блокировки этой буферизации.
Лекция №10
На прошлой лекции мы разобрали следующие моменты, связанные с организацией функционирования файловой системы. Это системная организация низкоуровнего обмена. Мы выяснили, что за счет организации данных, операционная система UNIX достаточно простыми и «прозрачными» средствами решает проблемы возможных конфликтов в случае нескольких открытий одного и того же файла. Мы видели, что все открытия одного и того же файла (под файлом мы понимаем не имя, а содержимое) в конечном итоге сводятся к работе с единственной копией ИД. Мы с вами выяснили, что почти все открытия файлов, связанные с одним ИД, порождают для процессов возможность работать со своими указателями чтения/записи по файлом, за исключением случаев, когда файл в процессе был получен через наследование, т.е. файл был получен от процесса-отца через функцию fork() процессом-сыном.
Мы с вами выяснили, что система подразделяет обслуживаемые устройства на два класса: блок-ориентированные и байт-ориентированные. Одно и то же устройство может одновременно быть и байт-ориентированным, и блок-ориентированным. Это зависит как от самого устройства, так и от наличия драйверов - программ управляющих этим устройством. Примером такого устройства является оперативная память.
Мы с вами рассмотрели принципы организации низкоуровнего обмена для блок-ориентированных устройств, и в контексте этого мы познакомились со средствами буферизации, которые применяются в ОС UNIX, суть которых заключается в том, что по аналогии с буферами чтения/записи из оперативной памяти (аппаратным средством), операционная система создает программные средства, которые позволяют минимизировать количество обращений к физическому устройству. Этот механизм выгодно отличал и отличает ОС UNIX. Здесь следует заметить, что буферизация обмена может быть многоуровневой. Первый дополнительный уровень может появиться за счет того, что устройство может иметь свои аппаратные буфера, реализованные по аналогии с буферами оперативной памяти.
Мы также говорили о том, что кроме низкоуровнего ввода/вывода, с которым связаны функции, обеспечивающие системные вызовы (open, read, write и т.д.), существуют высокоуровневые средства доступа - это стандартная библиотека ввода/вывода stdio.h, подключение которой позволяет использовать для организации обменов еще один уровень буферизации (это оптимизация обращений к системным вызовам), который ассоциирован с процессом, т.е. буферизация происходит за счет ресурсов процесса. Мы оценивали, что хорошо, что плохо. Очевидно, что буферизация сокращает количество обменов с медленным внешним устройством, и чем больше таких уровней, тем меньше происходит обменов. Однако плохо то, что за счет буферизации снижается надежность системы. Например, при неожиданном для системы выключении питания, все буфера теряют информацию. Момент обращения к обмену далек от реального обмена, и поэтому возможны неприятные ситуации. Но, несмотря на эти недостатки, опыт показывает, что фатальные потери информации происходят крайне редко.
Обращаю ваше внимание, насколько UNIX экономит обращения к ВЗУ. Суперблок находится в оперативной памяти, и реальные действия с информацией суперблока происходят не с диска, а из оперативной памяти, хотя здесь возникает та же проблема с несанкционированным выключением питания.
Открывая файл, мы работаем с ИД. Мы выяснили, что работа с ИД осуществляется через работу с его копией, размещенной в программных таблицах в оперативной памяти. Это означает, что почти нет накладных расходов, связанных с маленькими файлами, и эти накладные расходы малы при работе с огромными файлами. Получается так, что почти вся инфраструктура, поддерживающая работу файловой системы, работает за счет глубокой эшелонированной буферизации.
Атрибуты файлов
Любой пользователь принадлежит к группе. В соответствии с иерархией пользователей, определена иерархия защиты файлов и прав пользователей. Определено понятие владельца файла. Изначально владельцем файла является пользователь (а точнее, процесс пользователя), создавший этот файл. Атрибут «владелец файла» может быть изменен командой changeown. Каждый файл имеет атрибуты защиты, связанные с иерархией. Есть права доступа к некоторым действиям файла со стороны владельца файла. Это права на чтение, на запись, на исполнение. У каждого файла, кроме прав, связанных с уровнем пользователя, имеются права, связанные с уровнем группы. Это права для всех пользователей группы, к которой принадлежит владелец файла, за исключением его самого (т.е. права владельца и его группы различны). Третья категория защиты - все остальные. Это те права, которые имеют все пользователи системы, за исключением владельца и его группы. В системе имеется команда изменения прав доступа changemode.
Кроме атрибутов доступа, каждый файл может иметь признаки, в частности, т.н. t-бит и s-бит, которые также устанавливаются некоторой командой. Мы, уже зная структуру файловой системы, понимаем, что в принципе файл может находиться в очень сильно фрагментированном виде. Кроме того, файл может быть большим, а при открытии большого файла, возникают накладные расходы, связанные с доступом к далеким блокам файла. Поэтому открытие файла - это длительный процесс. Чтобы оптимизировать это действие, в системе имеется возможность пометить исполняемые файлы t-битом. После этого происходит следующее: в том случае, если вызывается исполняемый файл, помеченный t-битом, то при первом вызове за сеанс работы системы происходит копирование тела файла в область сохранения. При каждом повторном вызове файла, сначала происходит просмотр каталога области сохранения, и в том случае, если искомый файл там есть, то загрузка файла происходит не с ВЗУ, а из этой области. То есть это еще один путь минимизации обращений к ВЗУ. Обычно возможность установки t-бита - это прерогатива системного администратора, и системный администратор сам выбирает те процессы (и соответственно, файлы), которые надо пометить t-битом. Обычно им помечаются те процессы, которые используются наиболее часто (если, например, идет практикум, то t-битом имеет смысл пометить файл компилятора).
S-бит мы рассмотрим несколько поверхностно, но вернемся к нему позже. Есть следующая проблема. Все средства системы принадлежат кому-то, т.к. все средства, все команды (за исключением некоторых встроенных) в конечном счете представляют из себя файлы, у которых имеется владелец. Какие-то из этих команд могут обращаться в те или иные системные файлы. Возникает проблема, связанная с тем, что с одной стороны, должна быть защита от несанкционированного доступа к файлу. С другой стороны, все команды имеют потенциальные права для всех категорий. Как быть? Есть возможность помечать некоторые файлы s-битом. Владелец файла с s-битом остается неизменным, но при запуске этого файла, владельцу процесса запустившего этот файл, предоставляются права по доступу к данным от владельца исходного файла.
Предположим, есть исполняемый файл с именем file, и он работает каким-то образом с файлом file2, в котором находится конфиденциальная информация. Предположим, file корректирует file2, в котором находится информация обо всех зарегистрированных пользователях и, в частности, file может менять пароль пользователя в системе. Если я запущу file от своего имени, то могут возникнуть две ситуации: либо я не смогу работать с file2, в котором есть учетная информация о пользователях, потому что он закрыт для всех остальных; либо он открыт для всех, тогда нет никакой защиты. В этом случае работает s-бит. Суть его работы заключается в следующем. Владельцем исходного файла является пользователь ROOT. Предположим, этот файл захотел запустить пользователь с именем MASH. Если MASH запускает этот файл и нет s-бита, то получается, что владельцем файла является ROOT, а владельцем процесса стал MASH. В этом случае, файлы, которые недоступны пользователю MASH, будут недоступны и его процессу, и MASH не сможет изменить свой пароль в системе. S-бит позволяет продлить права владельца (ROOT) файла на владельца (MASH) процесса (запущенного из этого файла), и на время сеанса работы процесса ему будут доступны все те файлы, которые были доступны владельцу файла (ROOT).
Следующий вопрос: как интерпретируются права доступа к каталогам (поскольку каталоги также являются файлами)? Разрешение на чтение из каталога означает, что разрешен вход в каталог и открытие файлов из этого каталога. Разрешение на запись предоставляет возможность создавать и уничтожать файлы в этом каталоге. Разрешение на исполнение - это возможность поиска в данном каталоге (например, с помощью команды ls).
Файловая система с точки зрения пользователя.
Давайте рассмотрим структуру файловой системы с точки зрения пользователя. Эта структура будет рассматриваться для обобщенной операционной системы, так как реальная ее структура может варьироваться.
В корневом каталоге есть файл с именем unix. Это тот самый файл, который запускается программным загрузчиком, и который формирует ядро системы.
Каталог ETC. В этом каталоге находятся стандартные файлы данных системы и команды, обеспечивающие некоторый уровень управления функционированием системы. 1. Файл passwd. Все пользователи в системе зарегистрированы через этот файл. Это означает, что если пользователь может работать, то в файле passwd имеется строка, помеченная именем пользователя, которая содержит набор некоторых данных, разделенных символом разделителя. В частности, строка файла passwd содержит номер группы, к которой принадлежит пользователь, иногда может содержать закодированный пароль на вход пользователя в системе. Закодированный - означает то, что в системе используется взаимно неоднозначная возможность отображения последовательности символов в некоторый код, и в системе хранится отображение этого пароля. Современные UNIX-ы хранят пароли в отдельной защищенной базе данных (хотя файл passwd тоже присутствует), потому что файл passwd обычно открыт на чтение, алгоритм преобразования тоже обычно известен и есть возможность подобрать пароль.
Далее, строка содержит поле, в котором должен быть атрибут, характеризующий фамилию, имя и отчество пользователя; поле, в котором указывается статус пользователя; поле, в котором указан «домашний» каталог. В этой же строке указано (или может быть указано) с каким интерпретатором команд этот пользователь будет работать. Могут быть еще некоторые параметры.
2. Файл rc. В этом файле в текстовом виде находится набор команд, которые будут выполнены при загрузке операционной системы. Например, при загрузке, операционная система может запускать процесс проверки сохранности файловой системы.
Обращаю ваше внимание, что операционная система UNIX, за исключением нескольких случаев, содержит всю свою системную информацию в обыкновенных текстовых файлах. Эта информация легко просматривается и легко корректируется. В свое время, это был революционный шаг.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
