Поля, связанные с доступными возможностями

⇐ ПредыдущаяСтр 13 из 55Следующая ⇒

Традиционно UNIX-системы предлагают процессно-ориентированную защиту на действия и доступ к некоторым объектам, определяя каждый процесс как привилегированный (суперпользовательский или UID = 0) или непривилегированный (для любого другого процесса). Возможности были введены в Linux для отделения действий, которые ранее были доступны только в суперпользовательском режиме. Таким образом, возможности -это индивидуальные «привилегии», которые могут быть выданы процессу независимо от других процессов и от его UID. Таким образом, отдельные процессы могут получать возможность выполнять отдельные администраторские задачи без необходимости получать полные привилегии или являться собственностью суперпользователя. Такие возможности представляют собой отдельные администраторские операции. Рис. 3.6 демонстрирует поля, связанные с возможностями процесса.

3.2.5.1 cap_effective, capjnheritable, cap_permitted и keep_capabilities Структура используется для поддержки модели возможностей, определенной в include /linux/security.h как unsigned 32 битовое значение. Каждые 32 бита маски соответствуют набору возможностей; на каждую возможность отводится 1 бит:

• cap__ef f active. Возможность, уже используемая процессом.

• cap_inheritable. Возможность, передаваемая через вызов execve.

• cap permitted. Возможность, которая может быть как эффективной, так и наследуемой.

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

Глава 3 • Процессы: принципиальная модель выполнения

Current

task_struct


	...cap_effective...


	III...capjnheritable...


	...cap_permitted...	I

	keep_capabilities

Рис. З.б. Поля, связанные с доступными возможностями

собности, доступные одному из родителей, мы можем просто перечислить (эффективные возможности) и/или передать (наследование). Разрешенные возможности более похожи на потенциальные возможности, а эффективные возможности - на реальные.

Поэтому cap__ef f ective и cap_inheritable всегда являются подмножеством cap_permitted.

• keep_capabilities. Следит за тем, как процесс теряет или получает свои возможности при вызове setuid ().

В табл. 3.2 перечислены некоторые поддерживаемые возможности, определенные в

lunux/include/capability.h.

3.2 Описатель процесса

Таблица 3.2. Избранные возможности
Возможность Описание

CAP_CHOWN	Игнорирует ограничения, налагаемые chown ()
CAP_FOWNER	Игнорирует ограничения на доступ к файлам
CAP_PSETID	Игнорирует setuid и setgid ограничения для файлов
CAPJCILL	Игнорирует ruid и euid при посылке сигналов
CAP_SETGm	Игнорирует связанные с группой проверки
CAP_SETUID	Игнорирует связанные с uid проверки
CAP_SETCAP	Наделяет процесс полным набором возможностей

Ядро проверяет, какие из возможностей установлены при вызове capable () с передачей значений возможностей в качестве параметров. Обычно функция проверяет, какие из битов возможностей установлены в cap_ef f ective; если они установлены, функция устанавливает current-> flags в PF_SUPERPRIV, что означает получение возможностей. Функция возвращает 1, если возможность получена, и 0, если возможность не может быть получена.

С манипуляцией возможностями связано три системных вызова: capgetO, capset () и prctl (). Первые два позволяют процессу получать и устанавливать возможности, а системный вызов prctl () позволяет манипулировать current-> keep_capabilities.

Поля, связанные с ограничениями процесса

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

Rlim

Поле rlim содержит массив, позволяющий контролировать ресурсы и поддерживать

значения ограничений на ресурсы. Рис. 3.7 иллюстрирует поля rlim структуры task_

Struct.

Linux распознает необходимость ограничивать количество определенных ресурсов, которыми разрешено пользоваться процессу. В силу того что тип и количество используемых ресурсов может отличаться от процесса к процессу, необходимо хранить информацию о каждом процессе. Где же эту информацию разместить, как не в описателе процесса.

Глава 3 • Процессы: принципиальная модель выполнения

current-	^ task.struct

1 rlim_cur I		- RLIM.NUMITS
1 rlimjnax \|

1 rlim__cur 1
1 rlim_max \|
rlim
1 rlim_cur 1
1_____ rlim_max______ \|

Рис. 3.7. Ресурсные ограничения task_struct

Описатель rlimit (include/linux/resource.h) имеет поля rlim_cur и rlim_max, представляющие собой текущее и максимальное ограничения, налагаемые на ресурс. Тип ограничения варьируется от ресурса к ресурсу в зависимости от его типа.

include/linux/resource.h struct rlimit {

unsigned long rlim_cur;

unsigned long rlim_max; };

В табл. 3.3 перечислены ресурсы, для которых в include/asm/resource.h определены ограничения. При этом х86 и PowerPC имеют одни и те же ограничения на ресурсы и их значения по умолчанию.

Когда значение установлено в RLIMIT_INGINITY, ресурс для данного процесса не ограничен.

Описатель процесса

Таблица 3.3. Значения ограничений ресурсов

Имя ограничения ресурсов

Описание

Значение по умолчанию rlim_cur

Значение по умолчанию rlimjnax

RLIMIT_CPU

RLIMIT_FSIZE

RLIMIT_DATA

RLIMIT_STACK

RLIMIT_CORE

RLIMIT_RSS

RLIMIT_NPROC RLIMIT_NOFILE

RLIMIT_MEMLOCK

RLIMIT_AS

RLIMIT_LOCKS

Количество процессорного времени в секундах, выдаваемое процессу на выполнение

Размер файла в блоках по 1 кб

Размер кучи в байтах

Размер стека в байтах

Размер файла сброса ядра

Максимальный резидентный размер (реальной памяти)

Количество процессов, которые принадлежат данному процессу

Количество открытых файлов, которое этот процесс может иметь в каждый момент

Физическая память, которая может быть заблокирована (не свопирована)

Размер адресного пространства процесса в байтах

Количество блокировок файлов

RLIMIT_INGINITY RLIMIT_INGINITY

RLIMIT_INGINITY RLIMIT_INGINITY RLIMIT_INGINITY RLIMIT_INGINITY RLIMIT_INGINITY

RLIMIT_INGINITY

_STK_LIM

RLIMIT_INGINITY

INR_OPEN

INR OPEN

RLIMIT_INGINITY RLIMIT_INGINITY

Текущее ограничение (rlim_cur) - это мягкое ограничение, которое может быть изменено с помощью вызова setrlilimO. Максимальное ограничение определяется rlim_max и не может быть обойдено непривилегированным процессом. Системный вызов getrlimit () возвращает значение ограничения на ресурс. И setrlimit () и де-trlimit () получают в качестве параметра имя ресурса и указатель на структуру типа rlimit.

Глава 3 • Процессы: принципиальная модель выполнения

Поля, связанные с файловой системой и адресным пространством

Процессы могут быть тесно связаны с файлами на протяжении своего жизненного цикла, выполняя задачи наподобие открытия, закрытия, чтения и записи; task_struct имеет два поля, связанные с данными файлов и файловой системы: f s и files (см. гл. 6, «Файловые системы»). С адресным пространством связаны переменные active_mm и mm (см. описание mm_struct в гл. 4, «Управление памятью»). На рис. 3.8 показаны поля task_struct, связанные с файловой системой и адресным пространством.

	task_struct		fs.struct


		files_struct

fs

files

mm

actjve_mm


	mm_struct

Рис. 3.8. Поля, связанные с файловой системой и адресным пространством

Поле f s содержит указатель на информацию о файловой системе.

Files

Поле files хранит указатель на таблицу описателей файлов задачи. Этот файловый описатель хранит указатель на файлы (точнее говоря, на их описатели), открытые задачей.

3.3 Создание процессов: системные вызовы fork(), vforkQ и cloneQ

⇐ Предыдущая 8 9 10 11 121314 15 16 17 Следующая ⇒