Архитектура ЭВМ. Операционные системы

– реальный, подлинный; от αὐθέντης [authentes] – автор) – процедура

проверка подлинности пользователя.

Права доступа - совокупность правил, регламентирующих порядок и условия доступа субъекта к объектам информационной системы, установленных правовыми документами или собственником, владельцем информации.

для выполнения субъектам (например, пользователям системы) над объектами данных. Для

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

выдается (обычно - одно) входное имя (login name). Каждому входному

имени соответствует единственное число, идентификатор пользователя (User IDentifier, UID). Это число и есть ярлык субъекта, которым система пользуется для определения прав доступа.
Каждый пользователь входит в одну или более групп.
Группа - это образование, которое имеет собственный идентификатор группы (Group IDentifier), объединяет нескольких пользователей системы, а стало быть, соответствует понятию множественный субъект. Значит, GID - это ярлык множественного субъекта, каковых у действительного субъекта может быть более одного. Список GID субъекта однозначно соответствует его UID.

снабжен единственным UID: это идентификатор запустившего процесс пользователя. Любой процесс,

порожденный некоторым процессом, наследует его UID. Таким образом, все процессы, запускаемые по желанию пользователя, будут иметь его идентификатор. UID учитываются, например, когда один процесс посылает другому сигнал. В общем случае разрешается посылать сигналы "своим" процессам (тем, что имеют такой же UID). Классическое "Я тебя породил, я тебя и убью!" иллюстрируется еще и тем, что если процесс пытается убить родителя (послав ему тот или иной сигнал), то в лучшем случае ничего не происходит, чаще умирают оба, а иногда процесс, лишившийся родителя, превращается в зомби (его приходится убивать системе).

представленные в файловой системе: файлы, каталоги, устройства, каналы и т.

п. Каждый файл снабжен UID - идентификатором пользователя - хозяина. Вдобавок у файла есть единственный GID, определяющий группу, которой он принадлежит.

доступа: чтение (read, r ), запись (write, w ) и

исполнение (execution, x ).
Право на чтение из файла дает доступ к содержащейся в нем информации, а право записи - возможность ее изменять.
При каждом файле имеется список того, что с ним может делать хозяин (если совпадает UID процесса и файла), член группы (если совпадает GID) и кто угодно (если ничего не совпадает). Такой список весьма невелик (три категории субъектов по три способа доступа итого 9 записей вида "можно/нельзя", в целом чуть больше одного байта). Установленное право того или иного доступа называется атрибутом (соответственно r, w или x ).

x выдается программам и командным сценариям); именно среди файлов, которые

пользователю разрешено выполнять, shell ищет утилиту, с имени которой началась командная строка, а заставить выполниться файл, не имеющий атрибута x из командной строки, вообще невозможно. Право на чтение из каталога позволяет узнать только список файлов в нем (можно, например, написать cat каталог и увидеть малопонятную мешанину символов, в которой, однако, встретятся имена всех файлов в каталоге).

drwx--x--x 2 george staff 512 Dec 4 09:58 .
drwxr-xr-x 3 george staff 512 Dec 4 09:57 ..
-rw-r--r-- 1 george staff 135 Dec 4

создавать и удалять все, что в нем может содержаться. Это

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

можно разглядеть механизм доменной ответственности, который тесно связан с О.

Поскольку речь идет о правах, а не о сеансах доступа, мы имеем дело со статической моделью субъект-субъектных отношений со множественным субъектом. Множественный субъект в UNIX реализован не до конца. Дело в том, что при трех различных способах доступа мы имеем возможность задать объекту только одну группу. Это означает, что средствами chmod/chown невозможно создать такое положение вещей, когда одна группа пользователей могла бы только читать из файла, другая - только запускать его, а всем остальным файл вообще не был бы доступен.

субъект доступ к некоторому объекту, называется авторизацией. Выше описана статическая

схема авторизации в UNIX, основанная на постоянных правах доступа. В статической схеме вопрос о доступе решается один раз, когда права задаются или изменяются. Во время работы пользователя достаточно четко поставить ему в соответствие некоторый номинальный субъект системы, чтобы заработал механизм авторизации и система автоматически отказывала в доступе или предоставляла его.

со стороны действительного субъекта - тоже имеет место в UNIX,

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

в текстовом виде. Каждому пользователю соответствует одна строка, поля которой

разделяются двоеточиями

LOGNAME:*:UID:GID:GECOS:HOME:SHELL

UID и GID и играет роль доверенного субъекта UNIX. Это

значит, что он не подчиняется законам, которые управляют правами доступа, и может по своему усмотрению эти права изменять. Большинство настроек системы доступны для записи только суперпользователю (даже если файл имеет права доступа 0444, root все равно может в него писать). Вообще, root - страшный человек! Он может удалить все ваши файлы, хотите вы того или нет. Он может отредактировать /etc/passwd и вообще может все. Как правило, пароль root знает только системный администратор. В полном согласии с О, он отвечает за все, что творится в системе, - раз уж он все это в состоянии изменить. Именно суперпользователю принадлежит файл /etc/group, который определяет, в какие еще группы, помимо отмеченных в /etc/passwd, входят пользователи системы.

позволяет ему в дальнейшем "становиться любым пользователем", меняя собственные UID

и GID. Многие другие системные действия тоже требуют прав root, но по здравом рассуждении могут быть доверены обычному (не супер) пользователю. Например, управлять очередью отсылаемых электронных писем и передавать эти письма по назначению может процесс, не обладающий правами root, однако ему нужен полный доступ к очереди писем. С другой стороны, хорошо бы, чтобы никакой настоящий пользователь системы - человек не мог даже подглядеть в эту очередь. Так возникают псевдопользователи - учетные записи, к которым не подходит никакой пароль. Поле SHELL у псевдопользователя часто равно /sbin/nologin (программа выдает This account is currently not available и немедленно завершается), а поле HOME - /nonexistent (каталог, которого в системе нет). Зато система, запуская процесс "от имени" такого псевдопользователя, будет уверена, что ничего крамольного вне своей компетенции этот процесс не совершит даже в результате ошибки.

GECOS) с помощью команды passwd. Это простое и довольно обыденное

действие, с учетом всего сказанного выше, невозможно. В самом деле: процесс, запущенный пользователем, будет иметь его UID, а файл passwd принадлежит root, и только процессам с нулевым UID доступен для записи. Значит, необходим механизм подмены идентификатора, позволяющий обычным пользователям запускать процессы "от имени" других, в частности от имени root .
Для этого в файловой системе предусмотрено еще два атрибута - setuid и setgid. При запуске файла, имеющего атрибут setuid, система создает процесс, UID которого равен UID этого файла, а не UID процесса-родителя. Такова программа passwd: запустив ее, пользователь получает права root, но его действия ограничены возможностями этой программы.

никуда не делся, просто без него setuid все равно не

имеет смысла). Сходным образом работает и setgid, наследуя GID процесса от выполняемого файла. Подмена GID нужна в тех случаях, когда необходимо и открыть доступ к файлу, и сохранить реальный идентификатор пользователя - например, для записи рекордов в игре rogue. Кстати, бессмысленно ставить setuid или setgid сценариям, поскольку процесс запустится из файла, содержащего интерпретатор, а файл со сценарием будет всего лишь параметром командной строки.

дело весьма деликатное. Что если программа passwd имеет какие-нибудь еще

способности, кроме как изменять /etc/passwd строго в соответствии с документацией? Имея дело со свободно распространяемыми системами, мы всегда можем заглянуть в исходные тексты этой программы и убедиться, что авторы не имели в виду ничего предосудительного. Но вдруг у них случайно так вышло, что при определенных условиях passwd может запустить из текущего каталога программу с именем hack'em'all? Тогда все действия этой программы будут выполняться от имени root (наследование UID!) - действия, предусмотренные не системой, а каким-то бесправным пользователем, которому всего только и разрешено было что менять себе пароль.

фактический идентификатор ID пользователя в текущем процессе. geteuid возвращает эффективный идентификатор

ID пользователя в текущем процессе.
Фактический ID соответствует ID пользователя, который вызвал процесс. Эффективный ID соответствует установленному setuid биту на исполняемом файле.  

chmod(const char *path, mode_t mode);  int fchmod(int fildes, mode_t mode);  

Изменяет права доступа к файлу,

заданному параметром path или файловым дескриптором fildes. Права задаются применением логической операции OR  к константам.

struct stat *buf);  int fstat(int filedes, struct stat *buf);  int lstat(const char *file_name,

struct stat *buf);  
Функции возвращают информацию об указанном файле. Для этого не требуется иметь права доступа к файлу, хотя потребуются права поиска во всех каталогах, указанных в полном имени файла.
stat возвращает информацию о файле file_name и заполняет буфер buf.  lstat  идентична  stat, но в случае символьных сылок она возвращает информацию о самой ссылке, а не о файле, на который она указывает.  fstat  идентична  stat, только возвращается информация об открытом файле, на который указывает filedes (возвращаемый open(2)), а не о file_name.

inode */
mode_t st_mode; /* режим доступа */
nlink_t st_nlink;

/* количество жестких ссылок */
uid_t st_uid; /* идентификатор пользователя-владельца */
gid_t st_gid; /* идентификатор группы-владельца */
dev_t st_rdev; /* тип устройства (если это устройство) */
off_t st_size; /* общий размер в байтах */
blksize_t st_blksize; /* размер блока ввода-вывода в файловой системе */
blkcnt_t st_blocks; /* количество выделенных блоков */
time_t st_atime; /* время последнего доступа */
time_t st_mtime; /* время последней модификации */
time_t st_ctime; /* время последнего изменения */
};