АРХИВ СТАТЕЙ ЖУРНАЛА «МОЙ КОМПЬЮТЕР» ЗА 2002 ГОД

Права на доступа

• Все журналы \ Номер 38/209 `2002 от 30.09.2002 \ Права на доступа

Сергей ЯРЕМЧУК grinder@ua.fm

Настало время познакомить вас с одним из китов, на котором держится все Unix-системы, — о правах доступа. Фигурально говоря, это как раз та палка, которая рано или поздно выстрелит (или грабли, на которые наступят).

Итак, вы садитесь за компьютер, работа не идет, и в порыве вы случайно уничтожаете важные системные файлы. Или другая ситуация. Ваши знакомые или сослуживцы залезли в папку, которую не должны были видеть. Или… Примеров можно придумать сколько угодно. Ситуация, я думаю, знакомая. С одной стороны, это по-своему удобно: я сам себе режиссер, что хочу, то и делаю, любая программа или пользователь имеет доступ ко всем системным файлам и ресурсам, никаких ограничений нет. Красота! Вот только эпидемии вирусов иногда досаждают, система пошаливает, программы работают кривенько, ну и все такое. Как говорится, жить в обществе — пить из грязных стаканов. Так вот, в Linux этих проблем нет или почти нет. Почему?

Файлы в Linux имеют двух владельцев: пользователя (user owner) и группу (group owner), под которой понимается определенный список юзеров, причем владелец файла не обязательно должен быть членом группы, владеющей файлом. Каждый пользователь может быть членом сразу нескольких групп, одна из которых называется первичной (primary), а все остальные —дополнительными (supplementary). Это дает большую гибкость в организации доступа к определенному файлу. Совместное пользование некоторым ресурсом организовать очень просто — достаточно создать новую группу и включить в нее всех, кому это действительно необходимо. Если же человек, предположим, перешел в другой отдел, и уже нет необходимости в использовании данного файла, необходимо просто исключить его из состава данной группы. Ну, а что делать с остальными? Неужели они так и не смогут хотя бы прочитать содержимое файла? Или их придется каждый раз включать и исключать из группы? Для всех остальных (other), не принадлежащих ни к user owner, ни к group owner, права доступа устанавливаются отдельно и, как правило, самые минимальные. Обычно владельцем файла является пользователь, который его создал. Владелец-группа вновь создаваемого файла устанавливается равной первичной группе пользователя, создавшего файл, но в некоторых версиях Unix владелец-группа наследуется от владельца-группы каталога, в котором создается файл. Для изменения владельца файла используется команда chown, в качестве параметров принимающая имя нового владельца и список файлов (# chown new_owner file1 file2 …) Конечно же, на месте названия файла может быть и имя каталога, но при этом владелец файлов внутри каталога не изменится. Чтобы это произошло, лучше всего воспользоваться флагом -R (chown -R). При использовании данной команды по обыкновению можно применять регулярные выражения, если есть необходимость отобрать файлы, удовлетворяющие определенному критерию (chown -R lys *.с). Для изменения владельца группы используется команда chgrp, синтаксис ее аналогичен предыдущей команде (# chgrp sales /home/sales/*). Кстати, chown позволяет сразу установить и группу-владельца — для этого необходимо сразу после имени владельца без пробелов и других знаков поставить двоеточие и написать название необходимой группы (# chown — R sergej:gljuk *). Допускается и такой вариант записи: # chown — R :gljuk * — это аналог команды chgrp.

Принадлежность файла владельцу определяет те операции, которые над ним может совершить тот или иной пользователь. Самые очевидные из них — это смена владельца и группы для некоторого файла. Эти операции может проделать суперпользователь и владелец файла, в производных BSD UNIX — только суперпользователь. Но если вы напишете программу и захотите сделать ее владельцем, скажем, суперпользователя, у вас ничего не получится. А вот группу, если вы являетесь владельцем файла, можно изменить только на свою первичную (по умолчанию имеет то же название, что и имя соответствующего пользователя). Эти все ограничения введены по нескольким причинам: например, чтобы путем простого переопределения владельца нельзя было обойти лимит дискового пространства для конкретного пользователя, буде таковой установлен.

Следующие базовые операции, которые можно совершать над файлом, — это доступ на чтение (Read), запись (Write) и выполнение (eXecute). Они устанавливаются для каждой из трех групп пользователей раздельно. Причем проделать это может только пользователь-владелец и, конечно же, суперпользователь. Для установки соответствующих прав используется команда chmod. Применяется она в двух формах: абсолютной, когда игнорируются старые права, а безусловно устанавливаются новые, и относительной, когда к имеющимся правам что-то добавляется или, наоборот, отнимается. Абсолютная форма предполагает задание прав доступа к файлу в восьмеричной форме. Для того чтобы получить полный код необходимого режима файла, необходимо просто сложить значения кодов, приведенных в таблице.

Таким образом, команда # chmod 755 file устанавливает следующие права доступа: это исполняемый файл, запустить его на выполнение и прочитать содержимое имеют право все (т.е. владелец, группа и остальные), причем владелец дополнительно имеет право на изменение содержимого — запись. Это, кстати, пример задания прав классического CGI-сценария.

Относительная форма команды требует конкретного указания классов доступа (u — владелец, g — группа, o — остальные , a — все вместе), соответствующих прав доступа (r — чтение, w — запись, x — выполнение) и операции, которую необходимо произвести для списка файлов (+ — добавить, - — удалить, = — присвоить). Например, команда # chmod u+w, ug+r, a+x file добавляет дополнительно ко всем имеющимся правам право запустить файл на выполнение, группа и владелец смогут прочесть содержимое, а владелец, кроме того, изменить содержание.

Просмотреть соответствующие права доступа, а также владельца и группу можно с помощью команды ls -l:

Итого два:

Буква d означает, что это каталог, прочерк (-) — обыкновенный файл, l — символическая связь, b — блочное устройство, c — символьное устройство. Исполняемый файл может быть как откомпилированной программой (для его запуска необходимо только право на выполнение), так и скриптом. Чтобы запустить на выполнение последний, необходимо дополнительно право на чтение, так как программа-интерпретатор должна перед тем его прочитать. Значение прав доступа для различных типов файлов также варьируется. Вы ведь не забыли, что каталоги, устройства, сокеты и именованные каналы тоже являются файлами. Например, для последних трех задавать право на выполнение незачем. Для символических связей права доступа контролируются целевым файлом. Для каталогов они имеют немного другой смысл. Каталог по своей сути — файл, содержащий имена всех файлов, содержащихся в данном каталоге, а также указатели на дополнительную информацию, позволяющие операционной системе производить необходимые операции. Так вот, право на чтение каталога позволяет всего лишь получить имена файлов, находящихся в данной директории. А вот для того, чтобы получить дополнительную информацию, необходимы права на исполнение, так как уже придется заглянуть в «метаданные» каждого файла. Также, чтобы перейти в какой-нибудь вложенный каталог (cd), необходимо иметь права на выполнение всех указанных в пути. Пример: вы создали каталог для домашней страницы web-сервера Apache (public_html) и пытаетесь открыть его как http://localhost/~user_name, на что сервер объявляет, что узел не достижим. Одна из типичных причин — сервер попросту не может прочитать содержимое соответствующего каталога и всех директорий на пути к нему. Кстати, благодаря этому можно добиться так называемого эффекта dark directory, когда есть возможность создать каталог, файлы в котором доступны только пользователю, точно знающему имя соответствующего файла. Давайте посмотрим, как создать такой каталог.

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

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

Справедливости ради стоит сказать, что права доступа имеет не пользователь, а процесс, запущенный им. Не вдаваясь в подробности (о процессах разговор отдельный), каждый пользователь, зарегистрировавшись в системе, получает свою копию текущего процесса (shell), имеющую установленные идентификаторы RID и RGID — реальные индетификаторы пользователя и первичной группы пользователя. К чему это я, собственно? У нас остались без внимания три режима файла: бит сохранения задачи (stisky bit или save text mode), а также флаги SUID и SGID. Со stisky bit все просто, он указывает на необходимость сохранения копии выполняющейся программы в памяти после завершения выполнения. Этот режим позволяет сэкономить время на запуске часто использующейся программы, но в современных системах применение этого режима встречается редко. А вот флаги SUID и SGID позволяют изменить (расширить) права пользователя (группы), запустившего программу на выполнение, на время выполнения программы. Как уже говорилось, запущенное приложение имеет те же права доступа к системным ресурсам, что и пользователь, запустивший программу. Установка же этих флагов позволяет назначить права доступа исходя из прав доступа владельца файла. То есть, если владельцем запущенного приложения является root, то любой запустивший данное приложение будет иметь права суперпользователя. Конкретно, при установке флага SUID наследуется права владельца файла, а SGID — группы-владельца.

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

Как видите, все пользователи имеют право только на чтение файла /etc/passwd, а записывать информацию может только root (/etc/shadow, как видите, закрыли от всех, чтобы пароли не могли подобрать). Теперь смотрим на утилиту passwd:

Буква s означает, что установлен флаг SUID, а владельцем файла является его величество root — теперь кто бы ни запустил утилиту на выполнение, на время работы программы он временно получает права суперпользователя, т.е. может произвести запись в защищенный системный файл. Естественно, утилита должна производить изменение учетной записи только запустившего ее пользователя, что она и делает. Как вы понимаете, требования безопасности к программам, использующим данный метод, должны быть повышены. Это, наверное, самая опасная дыра во всех Unix — найдя ошибку в одной из программ, использующих биты SUID/SGID, можно производить любые действия, не обладая при этом правами суперпользователя. А аксиома программирования говорит, что ошибки будут всегда. Поэтому сейчас насколько это возможно пытаются изменить этот механизм. Да почитайте хотя бы аннотацию к большинству дистрибутивов Linux — производитель с гордостью сообщает, что такие то программы уже не используют механизм SUID/SGID! Возможный выход из положения: для установки битов SUID/SGID в символьной форме используется буква s, sticky bit устанавливается буквой t, а с помощью буквы l можно установить блокировку файла, тем самым предотвратив возможные конфликты, когда несколько процессов попытаются работать с одним и тем же файлом. И еще один интересный момент:

Смотрите, в каталоге /tmp установлен sticky bit. Зачем ? Как говорилось, предоставление права на запись в каталог позволяет пользователю удалять все файлы, даже те, владельцами которых он не является. Чтобы избежать этого, устанавливается sticky bit для каталога, и теперь удалить файл может только пользователь, создавший его. А при установке бита SGID для каталога все вновь созданные файлы будут наследовать группу не по пользователю, создавшему его, а по группе-владельцу каталога.

А теперь то, для чего все это, собственно, я вам рассказываю, т.е. о наших швабрах. Представьте себе такую ситуацию: смотрировали CD-ROM под root и скопировали с него файлы в домашний каталог обычного пользователя, поработали и выключили компьютер. Угадайте, на следующий день вы сможете открыть там хоть один файл? Да работать мне целую неделю в Windows, если да :-)! А все потому, что владельцем файла окажется все тот же суперпользователь. Это относится и к различным конфигурационным файлам, скопированным в домашний каталог (или созданным под root) — процесс, запущенный обычным пользователем, просто не сможет их прочитать, и пользоваться вы будете общесистемными, недоумевая, почему не вступают в силу настройки, произведенные вами. А вот еще ситуация: настроили принтер утилитой princonf, под обычным пользователем не печатает. Почему? А потому, что вам не дано право на выполнение. Самый радикальный метод из встреченных мной в книгах выглядит так:

Все получают право на выполнение, чтение и запись — и проблема решена; причем, проделав это сразу для всех файлов данного каталога, вы решите ее раз и навсегда. Для домашнего пользователя, в принципе, сойдет. Получится нечто вроде Windows. Более культурный вариант выглядит так:

Видите, право на выполнение дано root и членам группы lp — если вам нужен принтер, добавьте себя в эту группу. Сделать это можно либо прямым редактированием файла /etc/group (sergej:x:500:sergej,gdm,mysql,named,nobody,sound,lp), либо с помощью специализированных утилит вроде userconf или kuser (Рис. 1). Здесь мне мой Red Hat подкинул задачку:

И это сразу после установки! Получается, что только пользователь sergej сможет слушать музыку. Парадокс, однако. Пришлось создавать группу sound и добавить в нее себя, сделать владельцем обиженного root'a, а для группы sound определить чтение. Справедливости ради хотелось бы отметить, что права доступа — это заслуга не только операционки, но и файловой системы ext2. В inode файла внесена вся необходимая информация о соответствующих правах доступа. Аналогична ситуация и с Windows на ядре NT — будучи установлена на раздел FAT, она не ограничивает доступ, но если установить ее на родной NTFS, то получается весьма защищенная система с широкими возможностями по организации доступа пользователей.

В принципе, все. Бывшего пользователя Windows несколько раздражает, когда собственноручно созданный файл нельзя даже прочитать, но зато такой подход дисциплинирует. По этой же причине в Linux мало приживаются вирусы — чтобы нанести серьезный ущерб системе, нужны соответствующие права. По этой же причине не надо мне их больше высылать. Конечно, можно запустить ваши Klez'ы через эмулятор wine и посмотреть, что он будет делать во «вражьей» среде, но, поверьте, этого делать я не буду. При подготовке статьи использовалась музыка Rammstein :-). Linux forever.

Идёт загрузка...

Данную страницу никто не комментировал. Вы можете стать первым.

Ваше имя:
Ваша почта:
Комментарий:
Введите символы или вычислите пример: * Обновить