4. Эффективные и реальные идентификаторы

В слове защиты файла предусмотрены специальные биты, которые позволяют изменить идентификаторы пользователя и группы:

004000 - разрешение смены идентификатора пользователя при вызове файла, 002000 - разрешение смены идентификатора группы.

Зачем это нужно?

Дело в том, что первоначальные идентификаторы, связанные с процессом, называются реальными, а идентификаторы, полученные им после выполнения системного вызова ехес, - эффективными. Первоначально они всегда совпадают, но если в коде защиты файла предусмотрена смена идентификаторов, то после загрузки исполняемого файла по ехес реальные идентификаторы процесса изменяются на идентификаторы владельца (или группы) выполняемого файла, т. е. становятся эффективными.

Права доступа процесса проверяются по его эффективным идентификаторам.

Пусть, например, владельцем файлов данных dat1, dat2, dat3 является пользователь с идентификатором 1423. Любой доступ к этим файлам разрешен только их владельцу. Кроме того, имеются исполняемые файлы prog1, prog2, prog3, владельцем которых является тот же пользователь. Требуется, чтобы другие процессы, которые xoтят совершать операции над файлами dat1, dat2, dat3, могли это делать только при помощи программ prog1, prog2, prog3.

Для достижения этой цели в коде защиты файлов prog1, prog2, prog3 должна быть разрешена смена идентификатора пользователя для процесса, вызвавшего один из этих файлов. Тогда любой другой процесс, пожелавший работать с одним из файлов dat1, dat2 или dat3, должен вызвать по ехес соответствующую программу обработки prog1, ргоп2 или prog3, иначе он вообще не получит доступа к этим защищенным их владельцем файлам данных dat1, dat2, dat3.

Процесс может узнать cвои реальные и эффективные идентификаторы с помощью системных вызовов getuid, getgid getegid. Процесс может динамически изменять свои идентификаторы системными вызовами: setuid, selgid, однако это разрешено только привилегированному процессу или такому, у которого реальный идентификатор совпадает с устанавливаемым.

Специальная программа passwd позволяет изменить пароль пользователя в учетном файле пользователей /etc/passwd. Владельцем обоих этих файлов является пользователь с именем root. Код защиты учетного файл /etc/passwd позволяет записывать в него только владельцу, а код защиты. исполняемого файла passwd разрешает смену идентификатора пользователя.

Следовательно, пользователь, отличный от root, может изменить свой пароль только с помощью программы passwd. Тем самым соблюдается корректность по отношению к пользователю, который всегда может изменить свой пароль, не ставя в известность об этом системного администратора.

8. Свопинг и пейджинг в unix

Если UNIX инсталлирована на компьютере малой мощности с недостаточным количеством оперативной памяти, то описанная выше схема функционирования ОС в части диспетчеризации и управления процессами работает хорошо вначале, но рано или поздно память компьютера заполняется работающими процессами. После того как один из пользователей пожелает выполнить новую программу, диспетчеру необходимо найти способ поместить ее в память.

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

Представим себе, что существуют 3 процесса: а, b и с - и появляется заявка от пользователя на исполнение программы d. Поскольку в памяти нет места для процесса d, процесс а копируется на диск. После того как а будет скопирован на диск, копия d будет загружена в память на место а. После нескольких квантов времени диспетчер возвращает процесс а обратно в память и, как правило, заменяет им в памяти тот процесс, который находился там дольше всех. Предположим, что процесс а обменяется местами с процессом b. Первое, что нужно сделать, - это скопировать процесс b на диск. После этого а копируется обратно в память. Этот метод копирования процессов между диском и памятью продолжается до тех пор, пока не будет достаточно места для всех процессов, расположенных одновременно в памяти. Разумеется, это только примитивная иллюстрация действительной работы диспетчера UNIX.

В настоящее время большинство UNIX-систем вместо свопинга используют механизм, названный пейджингом. Он подобен свопингу, за исключением того, что на диск колируются части программ (страницы). Страницы обычно имеют фиксированный размер по 2048 или 4096 байт. Когда возникает потребность в памяти, одна из страниц копируется на диск, освобождая порцию памяти. Позднее, когда эта страница необходима использующей ее программе, она переносится обратно в память, возможно вытесняя на диск какую-нибудь другую страницу. Несмотря на то, что пейджинг сложнее свопинга, он работает более эффективно, потому что переносятся только малые части программ. Кроме того, если большая программа использует только малую часть памяти в течение времени своего выполнения, то лишь наиболее часто использованные порции программного кода будут постоянно присутствовать в дорогостоящей главной памяти.