Доступ к атрибутам
Каким образом пользователь может ознакомиться с атрибутами своей учетной записи? Ответ, как обычно в POSIX-системах, будет таким: разными способами. Правда, для этого ему нужно не только авторизоваться в системе (чему мы как-будто бы уже научились), но и суметь дать несколько команд. Собственно, команды - тема одной из , и потому пока я дам несколько примеров на уровне заклинаний (надеюсь, что скоро они перестанут казаться чем-то сверхъестественным).
Команда, позволяющая пользователю получить информацию о самом себе - это echo. Она просто выводит на экран те данные, которые получила в качестве ввода (например, с клавиатуры). Однако если за ней дать некоторые специальные символы (забегая вперед, скажу, что они называются переменными), то echo (как это ей и положено по званию) отразит на экране значения этих переменных.
Раз уж речь, опережая события, зашла о командах - начинающему пользователю (а читают эти строки, скорее всего, именно совсем начинающие - прочим уже давно надоело пережевывание известных им вещей) очень рекомендуется понемногу запоминать их - все они потребуются в ходе дальнейшего изложения.
Итак, первый резонный вопрос юзера - кто я? Для ответа на него командуем:
$ echo $USER
где символ $ после команды echo и пробела и обозначает, что все следующие символы являются переменной, а USER - имя данной конкретной переменной. Так вот, на эту команду мы незамедлительно получим ответ:
alv
свидетельствующий, что давший ее пользователь носит имя (login) alv. Ответом на запрос о программе, выполняющей роль пользовательской среды
$ echo $SHELL
будет ее имя, вместе с путем к исполняемому файлу:
/bin/tcsh
А если пользователя заинтересует место хранения собственных данных, следует спросить так:
$ echo $HOME /home/alv
где /home/alv - и есть домашний каталог пользователя alv (совпадение логина пользователя и имени его домашнего каталога - не обязательно, но, как правило, имеет место быть).
Однако наиболее полную информацию о себе пользователь может получить прямым просмотром базы пользовательских акаунтов.
База данных хранится в файле passwd каталога /etc (вопросы, что такое файл, каталог и почему его имя должно предваряться символом слэша - пока замнем для ясности, речь об этом будет в ). Пока для наших целей достаточно знать, что /etc/passwd - простой текстовый файл, доступный для чтения кому угодно - был бы инструмент для чтения. Забегая вперед, скажу, что, как и следовало ожидать, такой инструмент в POSIX-системах предоставляется, и даже не один. Хотя сейчас нам много не нужно - достаточно одного, наиболее удобного. Таковым в Linux выступает обычно команда less, а в BSD - еще и команда more (правда, как выяснится в , это одно и то же). И та, и другая требуют указания еще и имени просматриваемого файла. То есть в нашем случае это будет выглядеть так:
$ less /etc/passwd
или
$ more /etc/passwd
Вывод данной команды может выглядеть таким образом (на примере Archlinux, где этот файл умолчально устроен проще всего):
root:x:0:0:root:/root:/bin/zsh bin:x:1:1:bin:/bin: daemon:x:2:2:daemon:/sbin: mail:x:8:12:mail:/var/spool/mail: ftp:x:14:11:ftp:/home/ftp: nobody:x:99:99:nobody:/: alv:x:1000:100::/home/alv:/bin/zsh lis:x:1001:100::/home/lis:/bin/zsh
Из чего можно видеть, что мы действительно имеем дело с базой данных, хотя и очень простой по структуре. Любая же база данных, как известно, состоит из уникальных записей (или строк), относящихся к одному объекту базы, и составляющих запись полей, характеризующих свойства (сиречь атрибуты) этого объекта. Поля записи обязательно разделяются чем либо - в зависимости от формата базы это могут быть пробелы, символы табуляции, двоеточия (colon), точки с запятой (semicolon) и что-то еще.
Так и здесь: каждая строка представляет запись одного пользовательского акаунта - первым идет запись для суперпользователя, как ему по должности положено, следующие - это те самые псевдопользователи, которых мы договорись пока не трогать. а вот последние две записи - это уже акаунты реальных пользователей.
Наборы символов, разделенные символом двоеточия (:) - поля этой записи, описывающие каждый атрибут учетной записи (то есть colon - разделитель полей в нашей базе).
Считаем - атрибутов этих оказывается 7 (хотя и не все поля, как скоро станет ясно, обязательны к заполнению; и, напротив, некоторых атрибутов пользовательского акаунта в этой базе мы не увидим). Некоторые атрибуты нам уже знакомы, некоторые - нет. Тем не менее, пройдемся по ним по всем - ведь повторенье мать ученья.
На первом месте каждой записи, в соответствие с гуманистической ориентацией POSIX-систем, стоит имя пользователя, реального или виртуального, - не важно. Важно, что одинаковых мы среди них не найдем (в принципе можно создать пользователей с одинаковыми именами и разными численными идентификаторами, но ничего, кроме путаницы, это не даст).
Второе поле отведено под пароль пользователя. В данном случае оно заполнено символом x (или * - что почти равноценно). Это не значит, что нас посылают по известному на Руси адресу. Просто в файле /etc/passwd, вопреки его названию, реальных паролей не содержится - к этому вопросу мы еще вернемся.
Итак, с паролями пока проехали. Третье поле - самое важное: это и есть числовой идентификатор пользователя, служащий для однозначного его опознавания в системе. Аналогичен и смысл четвертого поля - только здесь стоит численный идентификатор основной группы, к которой пользователь приписан.
Пятое поле записи - так называемый комментарий. Для root'а и псевдопользователей здесь стоят некие условные значения, совпадающие с их именами. Что на деле отнюдь не обязательно - форма заполнения этого поля свободная. Так, для реальных пользователей здесь часто указываются их всамделишние ФИО по паспорту и любые другие данные, типа номера телефона. В приведенном примере для реальных пользователей "пункт пятый" просто оставлен пустым, так как своего имени и фамилии я пока не забыл. А во FreeBSD некоторые утилиты создания учетных записей пользователей обязательно потребуют придать этому полю какое-либо значение.
Шестое поле - домашний каталог пользователя. Для псевдопользователей тут опять же стоят некие непонятные имена - в некоторых случаях оно может быть и пустым.
А вот для пользователей реальных здесь указываются каталоги. куда они и в самом деле пишут свои данные. Суперпользователь в этом отношении похож на обычных пользователей - его домашний каталог /root также предназначен для собственных данных администратора. Как будет ясно в дальнейшем, выполнять от лица root'а какие-либо всамделишние пользовательские задачи - занятие крайне нездоровое, и потому домашний каталог суперюзера заполняется (обычно) исключительно его личными конфигурационными файлами (до которых тоже со временем дойдет дело).
И наконец, последнее поле записи - это имя той самой программы, которая выполняет роль среды обитания пользователя, запускаясь первой сразу же по его авторизации (опять несколько опережу события - в общем случае эта программа называется login shell). Можно видеть, что у псевдопользователей это поле пусто - они в такой среде не нуждаются. А вот root и тут проявляет свою человеческую сущность - и у него login shell имеется.
Вообще говоря, и для обычных пользователей заполнять седьмое поле записи не обязательно: в этом случае в качестве login shell для них будет запущена некоторая предопределенная по умолчанию среда (в POSIX-системах она всегда носит имя /bin/sh, хотя в реальности это могут быть разные программы).
В общем, из рассмотрения содержимого файла /etc/passwd мы узнали о пользователях, имеющих право на вхождение в данную систему, почти все. Однако слабо освещенным остался вопрос о группах - ведь вместо человечьего имени их в соответствующем поле стоит лишь нечленораздельный идентификатор. Что ж, дело легко поправимо - сведения о группах также хранится в специально предназначенном для этого файле, который называется (кто бы мог подумать) group и находится в том же каталоге /etc, где мы на него и посмотрим:
$ less /etc/group
Он выглядит примерно следующим образом (многоточиями я заменил группы псевдопользователей, которые в данный момент нас не волнуют - на самом деле здесь полторы дюжины записей):
root::0:root ... wheel::10:root,alv,lis ...
users::100:alv,lis sound:x:101:alv,lis
Можно видеть, что структура этого файла аналогична базе данных пользователей, но еще более проста - в каждой записи лишь четыре поля. Первое, как и следовало ожидать, - имя группы пользователей. Второе поле - пустое. В принципе оно предназначалось когда-то для пароля группы, однако по своему назначению ни в одной POSIX-системе, насколько мне известно, не используется. Третье поле - числовой идентификатор группы, тот самый, который мы уже видели в четвертом поле файла /etc/passwd.
Ну а здесь четвертое поле - это список пользователей, входящих в каждую группу. Как уже говорилось, каждый пользователь является членом минимум одной группы, которая называется основной. Однако это не мешает ему состоять, при необходимости, и в каких-либо иных группах. И это - очень эффективный механизм разграничения доступа к данным (или напротив, организации их совместной обработки разными пользователями).
Легко видеть, что root-оператор является единственным членом своей собственной группы (это характерно для большинства псевдопользовательских групп). А группа users объединяет двух пользователей, которые в моей системе являются реальными - и это их основная группа. Кроме того, оба они состоят еще и членами группы sound - без этого, как будет показано дальше, эти юзеры были бы лишены счастья слушать мою коллекцию авторской песни (и любые другие звуки - тоже).
Правда, и тот, и другой пользователь представляют собой мою скромную персону. Только не подумайте, что я страдаю раздвоением личности: просто alv - это тот пользователь, от лица которого я выполняю свою работу (например, пишу эти строки), а акаунт lis предназначен для всяких экспериментов с системой, более или менее нездоровых (зачем - станет ясным из одного из последующих разделов).
Особого внимания заслуживает группа wheel. Во многих Linux-дистрибутивах (и, добавлю, во всех BSD-системах) временно получить права администратора могут только члены этой группы (как - скажу чуть позже). В других системах это не так - впрочем, положение легко изменить как в ту, так и в другую сторону.
Потому что особый статус членов группы wheel зависит не от ОС или дистрибутива, а устанавливается в файле /etc/login.access. Где и может быть отменен при желании.
К группе wheel в BSD-системах приписано большинство исполнимых файлов базовой системы, расположенных в каталогах /{bin,sbin} и /usr/{bin,sbin} (забегая вперед, отмечу, что фигурные скобки символизируют группировку имен, то есть /{bin,sbin} эквивалентно /bin и /sbin).
Некоторые файлы из каталогов /{bin,sbin} и /usr/{bin,sbin} (напомню, что владельцев всех их является пользователь root) имеют, однако, иную групповую принадлежность. Возникает вопрос, для чего они предназначены? Это станет понятным после рассмотрения понятия файла и его атрибутов. Пока же замечу, что, например, членство в группах dialer и network необходимо для использования модемного и сетевого соединения, а членство в группе operator дает пользователю возможность завершать работу машины соответствующими командами, в иных случаях требующими полномочий администратора. Напомню, что это относится к BSD-системам - в различных дистрибутивах Linux и группы другие, и назначение их может быть разным.
Осталось прояснить вопрос с паролями. Мы уже видели, что в файле /etc/passwd никаких паролей на самом деле нет. На вопрос "почему" легко ответить словами Балбеса из "Операции Ы" - чтоб никто не догадался. Ведь если мы, будучи простым пользователем, легко получили доступ к содержимому столь, казалось бы, важного файла, то и для злоумышленника это труда не составит. Ибо право чтения файла /etc/passwd имеет любой пользователь (хотя вносить изменения в большинство записей и полей может только root). И потому для хранения паролей в большинстве дистрибутивов Linux предусмотрено специальное потайное место - файл /etc/shadow.
Впрочем, просмотреть его сразу нам не удастся - ведь мы зашли в систему в качестве обычного пользователя, а ему доступ к /etc/shadow запрещен под любым соусом (в том числе и просто для чтения). Что делать?
Парой абзацев выше я обмолвился о том, что есть возможность временно получить права администратора.
Для этого предназначена специальная команда - su (что иногда трактуют как аббревиатуру от Super User, но на самом деле означает Set UID, потому что она позволяет получить права не только администратора, но и любого другого пользователя - достаточно указать его имя в качестве аргумента). Данная же без всякого аргумента, в самой простой форме, как
$ su
она, однако, предоставляет доступ именно к суперпользовательскому акаунту, что чего сначала будет запрошен соответствующий пароль. Если мы его знаем и введем правильно - казалось бы, ничего не произойдет, никаких сообщений не последует. Правда, если присмотреться - окажется, что изменился вид приглашения командной строки (как - зависит от настроек командной оболочки, на которых пока задерживаться не будем). И это должно послужить сигналом к повышенному вниманию - с этого момент наш обычный пользователь наделен полномочиями root'а.
Почему требуется повышенное внимание? Да потому, что полномочия root'а, как будет рассказано в разделе о файлах и их атрибутах, практически ничем не ограничены. И он легко может по ошибке совершить какие-нибудь непоправимые действия, вплоть до полного разрушения системы.
Мы, однако не собираемся делать ничего брутального (или даже потенциально опасного). Нам бы только на файл с паролями полюбоваться - ведь теперь мы имеем на это право. Так что
$ less /etc/shadow
и вперед, удовлетворять свое любопытство (к тому же не без пользы).
Что же мы видим в нашем /etc/shadow? Да примерно такую же базу данных, что и раньше, о восьми полях. Первое поле - имя пользователя, реального или виртуального. Второе у псевдопользователей пусто. А у реальных (в том числе и у root'а) заполнено нечленораздельным набором символов. Это и есть пароль. Его представление в базе не имеет ничего общего с тем, что вводит пользователь при авторизации. Ибо пароль помещается в базу в односторонне зашифрованном виде. То есть по его представлению восстановить последовательность символов для ввода невозможно (как говорят эксперты по безопасности - невозможно в принципе; глядя на свой /etc/shadow, охотно им верю).
И односторонняя шифровка пароля - это первый эшелон обороны в Linux.
Если пароль нельзя расшифровать, то его можно подобрать. И представление зашифрованного пароля может помочь в этом черном деле. А потому доступ к файлу /etc/shadow закрыт для всех, кроме root'а - даже для просмотра. Что являет второй эшелон обороны Linux-системы.
Я не случайно в последних абзацах подчеркиваю, что речь здесь идет именно о Linux. Потому что такой механизм защиты (он называется механизмом теневых паролей - shadow passwords) принят именно в этой ОС (по крайней мере, в большинстве ее дистрибутивов). А вот в BSD-системах механизм теневых паролей не используется, а эшелонированная оборона достигается другим способом. Там в качестве дополнительного кольца защиты используется пара файлов: /etc/master.passwd и /etc/passwd. Первый из них, доступный только для root'а, содержит все данные о пользователе, включая его пароль, во втором, открытом для всеобщего обозрения, есть все то же самое - но без пароля.
К слову сказать, во FreeBSD оба эти файла существуют в двух вариантах - текстовом (собственно /etc/master.passwd и /etc/passwd), доступном для просмотра, и неудобочитаемом бинарном (/etc/master.spwd.db и /etc/spwd.db) Именно последние используются для идентификации пользователей: изменения, внесенные (скажем, в обычном редакторе) в текстовые варианты баз пользовательских акаунтов, должны быть соответствующим образом преобразованы. Что, кроме всего прочего, может рассматриваться как еще один эшелон обороны.
Завершая разговор о паролях, еще раз обратимся к файлу /etc/master.passwd из FreeBSD. Просмотр его показывает, что кроме полей, общих с файлом /etc/passwd, в нем можно видеть еще три. Они хранят информацию о времени последнего изменения пароля, а также могут определять всякие дополнительные сроки действия пароля, Например, здесь можно задать дату, когда пароль должен быть изменен, или дату, после которой вход по этому паролю в систему невозможен. Неконец, очень важное поле class (например, russian) позволяет определить некоторые свойства, общие для ряда пользователей.
