Файл passwd — это список пользователей, которые известны системе. В процессе регистрации пользователя система обращается к данному файлу в поисках идентификатора пользователя, а также с целью проверки входного пароля. Каждая строка файла описывает одного пользователя и содержит семь полей, разделенных двоеточиями:

• регистрационное имя;

• зашифрованный пароль (если не используется файл скрытых паролей; см. ниже);

• идентификатор пользователя;

• идентификатор группы по умолчанию;

• поле GECOS (полное имя, номер офиса, рабочий и домашний телефоны);

• начальный каталог;

• регистрационный интерпретатор команд.

Вот примеры правильно составленных строк файла /etc/passwd:

Файл /etc/passwd часто используется несколькими системами через СУБД, такую как NIS или NIS+. Более подробную информацию на эту тему вы найдете в главе 18.

Ниже рассматривается назначение отдельных полей файла /etc/passwd.

 

Регистрационное имя

 

Регистрационные имена (называемые также пользовательскими именами) должны быть уникальными. Как правило, они содержат не более восьми символов*. Если используется база данных NIS или NIS+, длина имени ограничена 8 символами независимо от операционной системы.

Ранее регистрационные имена могли состоять только из алфавитно-циф­ровых символов. В современных системах допускаются любые символы, кроме двоеточий и символов новой строки. Тем не менее, лучше придерживаться старых правил и не создавать имена длиной более 8 символов. Это позволит избежать конфликтов с почтовыми системами и старыми программами, а также гарантировать, что пользователи смогут иметь одинаковые регистрационные имена на любой машине. Помните: сегодня у вас одни компьютеры, а завтра могут быть другие.

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

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

Любая жестко заданная схема в конечном итоге приводит к появлению дубликатов имен или слишком длинных имен, поэтому иногда придется делать исключения. В случае появления длинного имени можно в файле /etc/mail/aliases задать две версии одного и того же имени, по крайней мере, для электронной почты.

 

 

Например, схема именования может быть такой: первый инициал и фамилия каждого сотрудника. Пользователь Брент Браунинг (Brent Browning), таким образом, превратится в "bbrowning", но девять символов — слишком много. Лучше присвоить этому пользователю регистрационное имя "brentb", a "bbrowning" сделать элементом файла aliases:

 

 

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

Когда пользователь работает за несколькими машинами, то регистрационные имена должны быть уникальными в двух аспектах. Во-первых, необходимо, чтобы имя конкретного пользователя на всех машинах было одним и тем же. Это предусматривается главным образом для удобства — самого пользователя и администратора.

Во-вторых, конкретное регистрационное имя всегда должно относиться к одному и тому же лицу. Если в сетевой среде одно имя принадлежит двум разным пользователям, это приводит к возникновению слабых мест в системе защиты. Например, если записи scott@boulder и scott@refuge относятся к разным пользователям, то при определенных обстоятельствах оба пользователя могут получить доступ к файлам друг друга.

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

 

Зашифрованный пароль

 

Пароли хранятся в файле /etc/passwd в зашифрованном виде. Если только вы не производите DES-кодирование в уме (в этом случае мы очень хотели бы с вами познакомиться), необходимо либо установить содержимое этого поля с помощью команды passwd (или yppasswd, если используется база данных NIS), либо скопировать строку, содержащую зашифрованный пароль, из другой учетной записи.

Редактируя файл /etc/passwd для создания новой учетной записи, в поле зашифрованного пароля поставьте звездочку (*). Она воспрепятствует несанкционированному использованию учетной записи до установки реального пароля. Никогда не оставляйте это поле пустым, иначе в системе защиты возникнет огромная брешь, поскольку для доступа к такой учетной записи пароль не требуется.

В системах, где применяются стандартные DES-пароли, длина незашифрованного пароля не может превышать 8 символов. Более длинные пароли допускаются, но значащими в них будут только первые 8 символов. Зашифрованный пароль будет иметь длину 13 символов независимо от длины исходного пароля. В алгоритме используется случайная двухсимвольная "примесь", чтобы одному исходному паролю соответствовало несколько зашифрованных форм. Таким образом, факт выбора пользователями одинаковых паролей не может быть выявлен путем просмотра файла passwd.

В HP-UX существует "доверительный режим", при котором допускаются пароли любой длины. Это достигается путем многократного применения алгоритма DES, по одному разу для каждого 8-символьного сегмента.

В Red Hat и FreeBSD поддерживаются пароли MD5, которые также могут иметь произвольную длину. Зашифрованные таким способом пароли легко распознать, так как они имеют длину 31 символ и всегда начинаются с последовательности

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

В Solaris теневые пароли обязательны. Необходимо модифицировать файл теневых паролей при подключении и отключении пользователей, чтобы он был согласован с файлом /etc/passwd. Структура файла shadow в Solaris описана в параграфе 6.4.

 

Идентификатор пользователя

 

В большинстве современных систем идентификатор пользователя (UID) — это 32-разрядное целое число в диапазоне от 0 до 2147483647. Но для обеспечения совместимости со старыми системами мы рекомендуем, чтобы значение самого старшего идентификатора по возможности не превышало 32767. В текущих версиях Linux максимальное значение UID равно 65535, но подобное положение может измениться в будущем.

По определению пользователь root имеет идентификатор 0. В большинстве систем есть также псевдопользователи bin (идентификатор 1) и daemon (идентификатор 2). Как правило, псевдоимена помещаются в начало файла /etc/passwd, и им назначаются низкие идентификаторы. Чтобы зарезервировать побольше номеров для неперсонифицированных пользователей, рекомендуем присваивать реальным пользователям идентификаторы, начиная с номера 100.

Нежелательно создавать более одной учетной записи с идентификатором 0. Может показаться удобным иметь несколько суперпользовательских записей с разными интерпретаторами команд и паролями, но в действительности это создает дополнительные бреши в системе защиты и приводит к лишним трудностям. Если нескольким пользователям необходимо быть администраторами, пусть они применяют команду sudo.

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

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

Трудно соблюдать уникальность идентификаторов, когда группы компьютеров администрируются разными лицами и даже организациями. Это проблема как техническая, так и политическая. Лучшим решением будет создание центральной базы данных, содержащей для каждого пользователя свою уникальную запись. Мы у себя самостоятельно создали такую базу данных и назвали ее Uniquid. Проще всего назначить каждой группе в пределах организации свой диапазон идентификаторов и позволить распоряжаться им по своему усмотрению. Проблема не решится полностью, но вероятность совпадений значительно уменьшится.

 

Идентификатор группы по умолчанию

 

Идентификатор группы (GID) представляет собой 16- или 32-разрядное целое число со знаком или без. Идентификатор 0 зарезервирован для группы с именем root или wheel, а идентификатор 1 обычно принадлежит группе daemon.

Группы определяются в файле /etc/group. В старых версиях UNIX пользователь мог быть членом только одной группы. Для выбора эффективного идентификатора группы, используемой по умолчанию при входе в систему, брали значение поля GID из файла /etc/passwd. Новейшие версии UNIX позволяют пользователю быть членом до 16 групп одновременно, поэтому поле GID в файле /etc/passwd никогда не используется и, по сути дела, является рудиментом старой эпохи. Тем не менее, значение поля продолжают включать в список групп пользователя.

В HP-UX список групп пользователя инициализируется во время регистрации на основании файла /etc/logingroup, а не /etc/group. Мы рекомендуем сделать файл /etc/logingroup символической ссылкой на файл /etc/group, чтобы ОС HP-UX вела себя так же, как и другие системы при работе в нескольких группах.

Единственный раз, когда эффективный идентификатор учитывается, — при создании новых файлов и каталогов. Если используется семантика BSD, новые файлы наследуют значение GID у своего родительского каталога. В противном случае им назначается текущий эффективный идентификатор группы, которой принадлежит владелец. Изменить этот идентификатор можно с помощью команды newgrp.

Большинство систем по умолчанию не используют семантику BSD, но ее можно активизировать с помощью опции grpid команды mount либо путем установки для нужных каталогов бита SGID (2000). Во FreeBSD этот режим всегда включен, так как в данной системе нет команды newgrp.

 

Поле GECOS

 

Поле GECOS не имеет четко определенного синтаксиса. Первоначально в Bell Labs его использовали для регистрации информации, необходимой при передаче пакетных заданий из UNIX-системы мэйнфрейму, работающему под управлением GECOS. Сейчас осталось одно название.

Как правило, это поле используют для хранения персональной информации о каждом пользователе. Некоторые программы заменяют символ '&' в поле GECOS регистрационным именем пользователя, что позволяет немного сократить объем вводимых данных. В частности, это относится к программам finger и sendmail. Лучше не полагаться на подобную возможность.

Программа finger интерпретирует разделенные запятыми элементы поля GECOS в следующем порядке:

• полное имя (часто используется только это поле);

• номер офиса;

• рабочий телефон;

• домашний телефон.

С помощью команды chfh (passwd -g в Solaris) можно изменять информацию, содержащуюся в поле GECOS. Эта команда полезна для ведения и обновления списка телефонных номеров, но ею часто злоупотребляют: пользователь может изменить информацию так, что она станет нецензурной или некорректной. В нашем факультетском компьютерном центре, который посещают толпы старшекурсников, эту команду пришлось отключить.

 

Начальный каталог

 

При входе в систему пользователь попадает в свой начальный каталог. Если на момент регистрации у пользователя нет начального каталога, выводится сообщение наподобие "no home directory" (начальный каталог отсутствует). В некоторых системах допускается продолжение процедуры регистрации, и пользователь попадает в корневой каталог. Есть системы, в которых регистрация без начального каталога не разрешена.

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

 

Регистрационный интерпретатор команд

 

В качестве регистрационного интерпретатора, как правило, задается Bourne shell или С shell (соответственно /bin/sh или /bin/csh), но в принципе это может быть любая программа. В большинстве систем по умолчанию используется интерпретатор Bourne shell, который запускается, если соответствующее поле в файле /etc/passwd не указано. К другим распространенным интерпретаторам относятся ksh (Korn shell), bash (Bourne-again shell) и tcsh (усовершенствованная разновидность С shell).

Во многих системах пользователи могут изменить интерпретатор с помощью команды chsh. В Solaris лишь суперпользователь имеет право менять интерпретатор другого пользователя (с помощью команды passwd -е), если только не используется база данных NIS или NIS+. Файл /etc/shells содержит список тех интерпретаторов, которые пользователь может выбирать с помощью команды chsh. Пользователь root может применять эту команду без ограничений. Проверьте, чтобы элементы файла /etc/shells

содержали полные имена команд.