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

Теги: Linux

Автор grinder, источник: http://www.linuxstudio.ru

Linux

Настало время поговорить о швабре на которую наступают новички. Речь сегодня пойдет о правах доступа. И так вы садитесь за компьютер, работа не идет и в порыве вы уничтожаете случайно важные системные файлы. Или ваши знакомые или сослуживцы залезли в папку которую не должны были видеть. Или ... Ситуация я думаю знакомая. Но зато согласитесь удобно. Я сам себе режиссер, что хочу то делаю, любая программа, пользователь имеет доступ ко всем системным файлам и ресурсам, никаких ограничений. Красота. Отсюда эпидемии вирусов. Так вот в 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. Применяется она в двух формах абсолютной - когда игнорируются старые права, а безусловно устанавливаются новые, и относительной - когда к имеющимся правам добавляются/убираются другие. Абсолютная форма предполагает задание прав доступа к файлу прямым заданием его в восьмеричной форме. Для того чтобы получить полный код необходимого режима файла, необходимо просто сложить значения кодов приведенных в таблице.

Восьмеричный код	Режим файла
0001	Право на выполнение для всех
0002	Право на запись для всех
0004	Право на чтение для всех
0010	Право на выполнение для группы
0020	Право на запись для группы
0040	Право на чтение для группы
0100	Право на выполнение для владельца
0200	Право на запись для владельца
0400	Право на чтение для владельца
1000	Включения бита сохранения задачи
2000	Если файл выполняемый включения бита SGID
4000	Если файл выполняемый включения бита SUID

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

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

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

[sergej@grinder sergej]$ ls -l

итого 2

drwxrwxr-x 2 sergej sergej 1024 Авг 17 09:45 bin
-rw-rw-r- 1 sergej sergej 604 Авг 22 21:07 printenv.pl

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

[sergej@grinder sergej]$ mkdir darkcat # создаем каталог

[sergej@grinder sergej]$ chmod a-r+x darkcat # устанавливает необходимые права доступа, добавляем исполнение для всех и убираем возможность чтения списка файлов

[sergej@grinder sergej]$ ls -l # маленькая проверка

d-wx-wx-x 2 sergej sergej 1024 Сен 7 15:14 darkcat

[sergej@grinder sergej]$ cp myfile darkcat # копируем файл в каталог

[sergej@grinder sergej]$ cd darkcat # переходим в каталог

[sergej@grinder darkcat]$ ls -l # пробуем прочитать список файлов

ls: .: Permission denied # вот те раз

[sergej@grinder darkcat]$ cat myfile # выводим содержимое файла на терминал

Получилось.

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

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

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

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

[sergej@grinder sergej]$ ls -l /etc/passwd /etc/shadow

-rw-r-r- 1 root root 1628 Авг 13 18:31 /etc/passwd

-r--- 1 root root 1081 Авг 13 18:31 /etc/shadow

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

[sergej@grinder sergej]$ ls -l /usr/bin/passwd

-r-s-x-x 1 root root 15104 Мар 14 03:44 /usr/bin/passwd

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

[sergej@grinder sergej]$ ls -l /

drwxrwxrwt 25 root root 4096 Сен 8 20:08 tmp

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

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

[root@grinder sergej]# chmod a+rwx /dev/*

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

[sergej@grinder sergej]$ ls -l /dev/lp0

crw-rw-- 1 root lp 6, 0 Апр 11 17:25 /dev/lp0

Видите право на выполнение дано root и членам группы lp, отсюда если нужен принтер добавьте себя в эту группу. Либо прямым редактированием файла /etc/group (sergej:x:500:sergej,gdm,mysql,named,nobody,sound,lp), либо с помощью различных графических утилит вроде System Setting.
Зачем все это?

Например не играет звук. Смотрим.

[sergej@grinder sergej]$ ls -l /dev/dsp

crw--- 1 sergej root 14, 3 Апр 11 17:25 /dev/dsp

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

Или например на форумах часто спрашивают как сделать чтобы ppp соединение было доступно обычному пользователю. А все просто. Не нужно ничего выдумывать. Ищем пользователя и группу которая имет доступ к этому сервису и добавляем себя любимого. В Ubuntu это группа dip.

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

Авторизуйтесь для добавления комментариев!