Европейский Университет в Санкт-Петербурге
Опубликован: 04.07.2008 | Доступ: свободный | Студентов: 1309 / 258 | Оценка: 4.34 / 3.65 | Длительность: 21:13:00
Лекция 5:

Управление пользователями

< Лекция 4 || Лекция 5: 1234 || Лекция 6 >
Ключевые слова: solaris, интерактивность, СУБД, Oracle, права, группа, пользователь, идентификатор, управление учетными записями, почтовый ящик, учётная запись, файл, t-бит, дополнительная группа, group, группа пользователей, запись, поле, Unix, ACL, аутентификация, авторизация, Web-службы, radius, authenticity, MODULE, PAM-5, администрирование, надежность, печать, администратор, запуск процесса, системный администратор, UID, создание файла, login, root, интерпретатор, командный интерпретатор, identification, идентифицирующая, GID, группа процессов, доступ к файлу, shadowing, system, CAT, имя пользователя, вход в систему, NP, идентификатор пользователя, координаты, пейджер, домашний каталог пользователя, сетевые службы, FTPD, домашний каталог, командный процессор, X-протокол, UserName, полное имя, идентификация, псевдопользователь, bin, мобильный телефон, generality, electrical, comprehensive, operating-system specific, locking, password, SMC, текстовый редактор, процессор, forwarder, история команд, history, skeleton, запись в файл, LDAP, имя группы, пароль группы, идентификатор группы, admin, solaris management console, графическая среда, Add, Wizard, системные программы, интерфейс командной строки, атрибут пользователя, учетная запись пользователя, freebsd, localization, bash, пароль

Зачем распределять пользователей по группам?

В Solaris есть ряд предопределенных групп. Большинство из них созданы для запуска системных процессов от имени этих групп. Одна из групп – staff – предназначена для того, чтобы ее членами были все обычные пользователи, которым разрешена интерактивная работа с системой Solaris. Некоторые приложения (например, sendmail или СУБД Oracle) требуют создания специфических групп с определенными именами. При необходимости вы можете создать новую группу и назначить ее в качестве главной или дополнительной группы тем пользователям, которым следует делегировать некие одинаковые (для группы) права.

Группа staff часто является главной группой большинства пользователей.

При добавлении пользователя с помощью команды useradd пользователь попадает в группу other, если явно не указано иное. Эта группа имеет идентификатор 1.

Смысл разделения пользователей на группы обсуждался ранее в "Solaris для простых задач начинающего" . При необходимости изменения учетной записи пользователя следует воспользоваться программами управления этими записями. Они описаны ниже в разделе "Программы управления учетными записями пользователей".

Когда вы планируете распределить пользователей по группам, удобно назначить им в качестве главной группы такую, которая бы соответствовала их основной роли в системе. Например, те пользователи, чья работа с системой будет ограничена получением почты из почтовых ящиков, должны быть отнесены к группе pop3 или imap4. Удобно дать таким группам имена, по которым вы сразу можете вспомнить, ради чего эта учетная запись вообще появилась в системе.

Представьте – после четвертой чашки кофе ваш взгляд упирается в файл /etc/passwd и в мозгу начинает неотвязно биться мысль: нет ли в системе лишних пользователей? Может быть, завалялись какие-нибудь устаревшие учетные записи и их можно вычистить? Открыв /etc/passwd, вы видите несколько сотен пользователей, полтора года назад отнесенных к группе pop3. Ага, догадываетесь вы, эти забирают почту с нашего сервера. А вот эти, из группы oldlamer, что тут делают?

После того, как пользователям назначена главная группа, каждый из них может быть добавлен в другие группы. Все группы, кроме главной, в которых участвует пользователь, называются дополнительными для этого пользователя. Для добавления пользователя в дополнительные группы следует использовать программы управления учетными записями. Эти программы изменяют файл /etc/group, так как именно этот файл хранит информацию о дополнительных группах пользователей. С другой стороны, вы можете вручную исправить запись о группе в /etc/group, указав в ее последнем поле через запятую тех пользователей, которых собираетесь добавить в эту группу, вот так:

sys::3:root,bin,adm,skomorox

Концепция безопасности UNIX

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

В современных системах UNIX для большей гибкости прав доступа введены дополнительные свойства объектов, такие, как флаги для файлов и каталогов, списки управления доступом (ACL) для файлов и каталогов, аутентификация и авторизация с использованием различных служб аутентификации подобных TACACS и RADIUS, а также модули аутентификации и авторизации (pluggable authentication modulesPAM). В этой книге TACACS и RADIUS не рассматриваются, а технология и настройки PAM обсуждаются в лекции 8 курса "Системное администрирование ОС Solaris 10".

Естественно, надежность усовершенствованной системы безопасности снизилась, а сложность администрирования выросла, как и при любом другом усложнении любой системы. Так что бесплатных пряников и в печи UNIX по-прежнему не пекут: чем более гибко настраивается система, тем внимательнее надо быть администратору при настройке.

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

Объект

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

Разделение всех пользователей по отношению к объекту

У каждого объекта есть владелец. Это – один из пользователей данной системы UNIX. Появление объектов, которыми владеют пользователи, не зарегистрированные в данной системе, – это ошибка системного администратора. Такое может произойти при разархивировании файла, созданного в другой системе. Если вместе с файлом была сохранена информация о его владельце, то легко может оказаться, что в другой системе есть пользователь с таким идентификатором (UID), а в нашей – нет.

Обратите внимание: для системы важны не имена пользователей, а их идентификаторы. Если в чужой системе есть пользователь ivan с UID, равным 1000, а в нашей ivan имеет UID, равный 2001, то при переносе файла с чужой системы к нам с сохранением информации о владельце файла в нашей системе появится "бесхозный" файл, если у нас нет пользователя с UID 1000, или принадлежащий тому пользователю, чей это UID, если такой найдется.

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

Однако, в ряде случаев запускаемый процесс будет принадлежать не тому, кто запустил процесс-родитель, а иному пользователю. Например, при входе пользователя в систему он сообщает имя и пароль программе login. Она работает от имени root (т.е. ее владельцем является пользователь root). Но программа login запускает для пользователя командный интерпретатор так, чтобы владельцем процесса командного интерпретатора был сам входящий в систему пользователь.

Любой объект имеет не только владельца, но и группу. Иногда владельца называют "хозяином", а группу – "группой владельца", "групповым владельцем", "групповым хозяином" и т.п. Смысл этого понятия в том, что каждому объекту в UNIX сопоставляется не только UID (user identificator), который идентифицирует владельца объекта, но и GID (group identificator), который идентифицирует группу пользователей, имеющую особые права на объект.

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

Назначение прав доступа по отдельности

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

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

Каждый объект имеет владельца и группу

Любой файл, каталог или процесс имеет владельца и группу. Это означает, что файлу, каталогу и процессу обязательно сопоставлены два идентификатора, которые называются UID (user ID) и GID (group ID) соответственно. Администрировать систему легче, если все объекты имеют UID и GID из числа представленных в /etc/passwd и /etc/group соответственно. "Бесхозные" объекты вносят сумятицу в стройные ряды прав доступа и делают права доступа к ним владельца и группы бессмысленными, ведь никто из пользователей не может получить "чужое" право доступа.

< Лекция 4 || Лекция 5: 1234 || Лекция 6 >
Александр Тагильцев
Александр Тагильцев

Где проводится профессиональная переподготовка "Системное администрирование Windows"? Что-то я не совсем понял как проводится обучение.

Александр Сурнин
Александр Сурнин
Россия, Архангельск, Архангельский Государственный Технический Университет, 2003