Пользователи и группы Linux

Как было указано ранее, для начала работы в многопользовательской операционной системе пользователю необходимо «зарегистрироваться», предъявляя имя своей пользовательской учетной записи и пароль, подтверждающий праве) на ее использование.

В результате регистрации в системе запускается командный интерпретатор — первая программа пользовательского сеанса.

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

Различают пользовательские и групповые учетные записи, при этом каждая пользовательская учетная запись идентифицируется уникальным числовым «пользовательским идентификатором» — UID (User Identifier), а каждая групповая — таким же уникальным числовым «групповым идентификатором» GID (Group Identifier). Именно эти числовые идентификаторы и используются ядром операционной системы при определении и проверке прав доступа субъектов относительно объектов.

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

Пользовательские идентификаторы UID и GIO первичной и дополнительных групп

john@ubuntu:~$ id

uid=1000(john)  gid=1000(john)  группы=1000(john),4(adm),… ,109(sambashare),110(admin)

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

Исторически сложилось, что в ранней UNIX членство пользователей в группах определялось динамически, т. е. после регистрации пользователя в системе ему (точнее — его процессу) выдавался идентификатор (и, как следствие, права доступа) только одной группы.

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

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

Кроме этих основных свойств, каждая учетная запись характеризуется именем домашнего каталога и именем командного интерпретатора (запускаемого при регистрации в системе).

Дополнительно, учетная запись пользователя может содержать полное имя пользователя, рабочий и домашний телефоны, рабочий адрес и прочую информацию, которую можно посмотреть при помощи pinky(1) и finger(1), а изменить при помощи chfn(1).

Свойства учетной записи пользователя

Учетная запись системного администратора с привилегированными (а точнее — неограниченными в буквальном смысле) правами доступа обычно называется root и всегда имеет идентификатор UID=0.

Учетные записи, «от лица которых» выполняются процессы системных служб, называются псевдопользовательскими и идентифицируются в диапазоне UID=i—499 или UID=1—999, а начиная с UID=500 (redhat) или UID=1000 (debian) и далее идентифицируются учетные записи обычных пользователей.

Передача полномочий

Для выполнения определенных административных (привилегированных) действий, например для установки системного времени при помощи команды date(1), нужны права доступа к определенным системным вызовам.

В классической UNIX были предусмотрены простые правила разграничения «все или ничего», т. все привилегированные действия были разрешены суперпользователю root с UID=0, и никакие привилегированные — всем остальным пользователям.

На текущий момент времени в Linux реализована система POSlX.1e привилегий capabilities(7).

В этих и подобных ситуациях для администрирования операционной системы непривилегированным пользователям необходимо временно воспользоваться правами суперпользователя, что реализуется посредством классической команды явной передачи полномочий su(1) — switch user, или более поздней команды sudo(1) — switch user do контролируемой передачи полномочий.

Основное различие между su(1) и sudo(1) заключается в том, что команда su реализует «повторную регистрацию в системе», требуя указать имя и ввести пароль того пользователя, чьи полномочия нужно получить. Напротив, команда sudo реализует явные правила sudoers(5) передачи полномочий, указанные в файле /etc/sudoers, и требует подтвердить передачу полномочий паролем того пользователя, который получает передаваемые полномочия.

Нужно заметить, что в Ubuntir Linux пароль суперпользователя root заблокирован, что не позволяет использовать учетную запись как «обычную» для регистрации в системе и превращает ее в «ролевую». Как следствие, привилегиями «роли» суперпользователя можно пользоваться лишь при помощи sudo и только непривилегированным пользователям, явно указанным в правилах передачи sudoers(5).

Хранилища учетных записей

Информация об идентификаторах UID и GID, именах пользователей и групп, их паролях и прочих свойствах учетных записей размещается (в простейшем случае) в файловых «хранилищах,»-Добычных текстовых файлах каталога /etc, формируя базы данных пользовательских /etc/passwd, /etc/shadow и групповых /etc/group, /etc/gshadow учетных записей. формат и структура этих файлов хорошо документированы в руководстве passwd(5), shadow(5) и group(5), gshadow(5) и представляют собой простейшие текстовые таблицы, где свойства каждой учетной записи представлены набором столбцов одной строки, разделенных символом двоеточия : .

Базы данных пользовательских учетных записей

john@ubuntu:~$ cat /etc/passwd

root:x:0:0:root:/root:/bin/bash

. . .                                  . . .

dvk:x:1000:1000: Alexey Ivanov,,+7(805) 530-01-04,,:/hone/dvk:/bin/bash

. . .                                  . . .

finn@ubuntu:~$ cat /etc/group

. . .

dvk:x:1000:

lpadmin:x:108:dvk

sambashare:x:109:dvk

admin:x:110:dvk

. . .

При использовании «коммутатора службы имен» (NSS, W: [Name Service Switch]) имеется возможность хранить базы данных учетных записей в любых хранилищах, включая сетевые службы каталогов NIS, NIS+, LDAP, активный каталог Microsoft Windows и даже реляционные сетевые базы данных SQL— при помощи соответствующих модулей NSS  и согласно настройкам коммутатора nsswitch.conf(5).

Хранилища пользовательских учетных записей и модули NSS