Права доступа в Linux, еще одна маленькая шпаргалка
Очередная шпаргалка на блоге, которая поможет быстро получить информацию об управлении правами доступа в ОС UNIX.
Общие понятия:
У каждого объекта в Linux есть свой идентификатор, а так же права доступа, применяемые к данному идентификатору. Идентификатор есть у пользователя – UID, у группы – GID, у файла – inod. Собственно inode является, как идентификатором файла/каталога, так и сущностью, которая содержит в себе информацию о файле/каталоге. Например такую, как: принадлежность к владельцу/группе, тип файла и права доступа к файлу.
Чтобы визуально лицезреть права доступа к файлу или каталогу, его тип и владельцев, а так же, если необходимо, и сам номер inode, необходимо выполнить следующую команду:
Print-server:/# ls -li итого 50 22089 drwxr-xr-x 2 root root 3072 Ноя 15 14:15 bin 32129 drwxr-xr-x 3 root root 1024 Окт 1 18:03 boot 12 lrwxrwxrwx 1 root root 11 Окт 1 15:36 cdrom -> media/cdrom 557 drwxr-xr-x 13 root root 3340 Ноя 17 06:25 dev 30121 drwxr-xr-x 50 root root 4096 Ноя 15 14:46 etc ....
Из вывода команды видно (рассмотрим первую строку):
22089
это есть номер inode
drwxr-xr-x
это есть те самые права доступа и тип файла (об этом ниже)
2
количество жестких ссылок на файл
root
имя владельца файла
root
имя группы владельца файла
3072
размер файла
Ноя 15 14:15
дата создания файла
bin
имя файла/каталога
Для каждого объекта файловой системы в модели полномочий Linux есть три типа полномочий: полномочия чтения (r от read), записи (w от write) и выполнения (x от execution). В полномочия записи входят также возможности удаления и изменения объекта. Право выполнения можно установить для любого файла. Потенциально, любой файл в системе можно запустить на выполнение, как программу в Windows. В Linux является ли файл исполняемым или нет, определяется не по его расширению, а по правам доступа. Кроме того, эти полномочия указываются отдельно для владельца файла, членов группы файла и для всех остальных.
Собрав вышесказанное в кучу, то есть представив 3 правила (rwx) для трех групп (владелец, группа, остальные) запись прав доступа будет выглядеть вот так: rwx rwx rwx(то есть владельцу разрешено чтение, выполнение и запись, группе разрешено то же самое и остальным). Рассмотрев права на папку /bin в выше приведенном листинге, можно представить такую картину:
drwxr-xr-x+ ||||||||||+наличие дополнительных прав (ACL) |||||||||+-исполнение для всех остальных - разрешено ||||||||+--запись для всех остальных - НЕ разрешено |||||||+---чтение для всех остальных - разрешено ||||||+----исполнение для группы владельца - разрешено |||||+-----запись для группы владельца - НЕ разрешено ||||+------чтение для группы владельца - разрешено |||+-------исполнение для владельца - разрешено ||+--------запись для владельца - разрешено |+---------чтение для владельца - разрешено +----------тип файла (об этом ниже...)
Кроме указанного представления полномочий доступа (символьного), существует так же и числовое представление. Для общего понимания, приведу таблицу соответствия числового (двоичного и десятичного) значения прав доступа и буквенного:
владелец | группа | остальные | |
буквенное | rwx | r-x | r– |
числовое (десятичное) | 421 | 401 | 400 |
итоговое | 7 | 5 | 4 |
В приведенной таблице показано, что право чтения, соответствует значению 4, право записи – 2, право выполнения – 1, отсутствие права – 0, складывая данные показатели, можно представлять и назначать права в числовом виде. Для примера, права rwx r-x r– будут соответствовать значению 754, потому что: rwx (4+2+1=7) r-x (4+0+1=5) r– (4+0+0=4). Так же, довольно распространена комбинация rw- (4+2+0=6). Думаю данный пример достаточно нагляден.
Особенности прав доступа для каталогов
Права доступа для каталогов немного отличаются. Это в первую очередь связано с тем, что система трактует операции чтения и записи для каталогов отлично от остальных файлов. Право чтения каталога позволяет Вам получить имена (и только имена) файлов, находящихся в данном каталоге. Чтобы получить дополнительную информацию о файлах каталога (например, подробный листинг команды ls -l), системы придется “заглянуть” в метаданные файлов, что требует права на выполнения для каталога. Право на выполнение также потребуется для каталога, в который Вы захотите перейти (т.е. сделать его текущим) с помощью команды cd. Итого, право чтения на каталог, позволяет читать имя содержимого, право выполнения – чтение содержимого с метаданными (правами и др.)
Управление правами доступа
Управление правами доступа происходит с помощью команды chmod, управление владельцем файла происходит с помощью команды chown.
Синтаксис команд следующий:
chmod [к_какой_группе_прав][что_сделать_с_правами][какие_права] над_каким_объектом
или
chmod [права] над_чем
где:
к_какой_группе_прав
может быть u (от user) – владелец-пользователь, g (от group) – владелец-группа, o (от other) – остальные пользователи, a (от all) – все вышеперечисленные группы вместе
что_сделать_с_правами
может быть + – добавить, – -убрать, = – присвоить указанное
какие_права
может быть: r- чтение, w – запись, x – выполнение
над_каким_объектом
соответственно – имя или путь к файлу
права
числовое обозначение прав доступа (755, 644 и т.п.)
пример:
[Print-server]$ chmod a=rw file [Print-server]$ ls -l file -rw-rw-rw- 1 user users 78 Nov 20 file
это будет аналогично:
[Print-server]$ chmod ugo=rw file1 [Print-server]$ ls -l file1 -rw-rw-rw- 1 user users 78 Nov 20 file1
а так же:
[Print-server]$ chmod 666 file2 [Print-server]$ ls -l file2 -rw-rw-rw- 1 user users 78 Nov 20 file2
Использование команды chown выглядит следующим образом:
chown user:group file
сменить владельцев файла file на user:group.
Дополнительные атрибуты файлов в Linux (sticky bit, SGID, SUID)
В Linux кроме прав чтения, выполнения и записи, есть еще 3 дополнительных атрибута:
1. Sticky bit (он же бит закрепления в памяти)
sticky bit появился в пятой редакции UNIX в 1974 году для использования в исполняемый файлах. Он применялся для уменьшения времени загрузки наиболее часто используемых программ. После закрытия программы код и данные оставались в памяти, а следующий запуск происходил быстрее. (отсюда и название – бит закрепления в памяти)
Сегодня sticky bit используется в основном для каталогов, чтобы защитить в них файлы. В такой каталог может писать ЛЮБОЙ пользователь. Из такой директории пользователь может удалить только те файлы, владельцем которых он является. Примером может служить директория /tmp, в которой запись открыта для всех пользователей, но нежелательно удаление чужих файлов.
Атрибут исполняемого файла, позволяющий запустить его с правами владельца. В Unix-подобных системах приложение запускается с правами пользователя, запустившего указанное приложение. Это обеспечивает дополнительную безопасность т.к. процесс с правами пользователя не сможет получить доступ на запись к важным системным файлам, например /etc/passwd, который принадлежит суперпользователю root. Если на исполняемый файл установлен бит suid, то при выполнении эта программа автоматически меняет “эффективный userID” на идентификатор того юзера, который является владельцем этого файла. То есть, не зависимо от того – кто запускает эту программу, она при выполнении имеет права хозяина этого файла.
Аналогичен SUID, но относиться к группе. При этом, если для каталога установлен бит SGID, то создаваемые в нем объекты будут получать группу владельца каталога, а не пользователя.
Хотелось бы так же провести аналогию с ОС Windows. В указанной операционной системе права регулируются на основе списков ACL. В Linux тоже такое возможно, это реализуется с помощью пакета acl, но данный вопрос в текущей теме я рассматривать не буду. Еще одно важное замечание! В Windows можно определить права доступа на каталог, и они автоматически распространяются на все файлы и поддиректории (если вы явно не указали иного). В Linux права доступа сохраняются в inode файла, и поскольку inode у каждого файла свой собственный, права доступа у каждого файла свои. Так же, права доступа пользователя и группы не суммируются, как в Windows. Если программа выполняется с правами пользователя и группы, которым принадлежит файл — работают только права хозяина файла.
Исполняемый файл с установленным атрибутом suid является “потенциально опасным”. Без установленного атрибута, файл не позволит обычному пользователю сделать то, что выходит за пределы прав пользователя (пример, программа passwd позволяет пользователю изменить только собственный пароль). Но, даже незначительная ошибка в такой программе может привести к тому, что злоумышленник сможет заставить её выполнить ещё какие-нибудь действия, не предусмотренные автором программы. Стоит очень осторожно относиться к данным атрибутам! Как найти в системе файлы с атрибутом SIUD и др.
При создании новой директории в директории с уже установленным SGID-битом, у созданной директории SGID-бит устанавливается автоматически!
Обозначение атрибутов Sticky, SUID, SGID
Специальные права используются довольно редко, поэтому при выводе программы ls -l символ, обозначающий указанные атрибуты, закрывает символ стандартных прав доступа. Пример: rwsrwsrwt, где s – SUID, s – SGID, t – Sticky. В приведенном примере не понятно, rwt — это rw- или rwx? Определить, стоит ли символ стандартных прав доступа под символами s и t – просто. Если t маленькое, значит x установлен. Если T большое, значит x не установлен. То же самое правило распространяется и на s.
В числовом эквиваленте данные атрибуты определяются первым символом при четырехзначном обозначении (который часто опускается при назначении прав), например в правах 1777 – символ 1 обозначает sticky bit. Остальные атрибуты имеют следующие числовое соответствие:
- 1 – sticky bit
- 2 – SGID
- 4 – SUID
Права доступа к символьным ссылкам
Если посмотреть на права символьных ссылок, то они всегда выглядят так: rwxrwxrwx. Дело в том, что права на символьную ссылку не имеют особого значения. При использования ссылки драйвер файловой системы пересчитывает реальный путь к файлу и применяет права доступа, определенные для реального пути уже без учета символьной ссылки.
Права доступа по-умолчанию для вновь создаваемых объектов ФС (umask)
В Linux, при создании какого-либо файла или каталога предоставляемые права определяются по определенному алгоритму (формуле). Не вдаваясь в подробности и для большего понимания сути. Скажу, что есть исходные права доступа (0666- для файлов и 0777 – для каталогов), и есть такая штука как umask, которая задана для каждого пользователя и хранится в виде строчки umask значение_umask в файле .bash_profile. Итого, у вновь создаваемого каталога будут права =исходные права доступа – umask.
Узнать текущий umask можно, введя команду umask без параметров.
Пример:
[root@proxy test]# umask 0022 [root@proxy test]# touch file [root@proxy test]# mkdir test [root@proxy test]# ls -l total 4 -rw-r--r-- 1 root root 0 Nov 23 14:51 file drwxr-xr-x 2 root root 4096 Nov 23 14:51 test
Как видно из примера, umask установлен 0022, исходные права доступа равны 0666- для файлов и 0777 – для каталогов. В результате получаем:
0666 – 0022 = 0644 (что соответствует правам -rw-r–r– для file)
0777 – 0022 = 0755 (что соответствует правам -rwxr-xr-x для каталога test)
В данном абзаце имеется некоторая неточность в формулировке, поэтому стоит учитывать комментарий пользователя Vadim.
Давайте попробуем подвести итог нашему прочитанному материалу:
Существует 3 разновидности прав rwx, которые соответствуют чтение запись исполнение соответственно. Так же, права назначаются для 3х сущностей: rwx rwx rwx, что соответствует владелец, группа и все остальные соответственно. Буквенному обозначению прав доступа соответствуют числовые аналоги для упрощения управления. Права доступа к файлам и директориям имеют различное значение. Для файлов:
r — право на чтение данных из файла.
w — право на изменение содержимого файла (запись).
x — право на исполнение файла.
Права доступа к директориям имеют другое значение:
r — право на чтение директории. Прочитать содержимое директории — получить список файлов.
w — право на изменение содержимого директории — создание и удаление файлов в этой директории.
x — право на «вхождение» в директорию.
Так же есть дополнительные атрибуты sticky bit, SUID и SGID, которые позволяют производить дополнительные специфические манипуляции с объектами файловой системы.
Права в Linux регулируются программной chmod, владельца объекта файловой системы можно изменить с помощью команды chown.
При создание новых файлов и каталогов в Linux есть права “по-умолчанию”, которые заданы значением umask.
На этом ставлю точку. Надеюсь, что объяснил все понятно и доходчиво. Буду рад любым комментариям и дополнениям.
Полезно
Онлайн калькулятор прав: http://permissions-calculator.org/
С Уважением, Mc.Sim!
Другие материалы в категории основы Linux
- Текстовый редактор VIM, основы работы
- ddrescue или спасаем данные с HDD
- Резервное копирование файлов сайта по ssh
- Седьмой релиз Debian
- Использование ramdisk в Linux (ramdisk, ramfs, tmpfs) или препарирование рамдисков
- SNMP протокол (основы)
- Установка антивирусного сканера ClamAV на Debian
- HOWTO использование backports в Debian
- Конспект установки Debian на сервер
- SSH сервер на Debian
В разделе
Обозначение атрибутов Sticky, SUID, SGID
написано:
В приведенном примере понятно, rwt — это rw- или rwx?
Наверное надо вставить “не”?
В приведенном примере не понятно, rwt — это rw- или rwx?
Александр, спасибо огромное за замечание. Исправил досадное упущение.
0777 – 0022 = 0755 (что соответствует правам rw-r–r– для каталога test)
может 0755 = -rwxr-xr-x ?
funt, да, действительно так!
Спасибо за дополнение. Это все невнимательный копипаст строчек.
Подскажите пожалуйста, как установить право на каталог формы drwxrws–t?
Как должна выглядеть команда?
какой числовой код имеют эти права?
Думаю как-то так. drwxrws–t:
d – каталог
rwx – права для владельца на чтение, запись, выполнение – 7
rws – права для группы на чтение, запись + SGID (с правом исполнения, потому что s -маленькая) – 7 + добавляется значение SGID = 2 перед общими правами
-–t – Sticky бит (с правом исполнения, потому что t маленькая) – 1 + суммируется значение Sticky бит = 1 к праву SGID перед общими правами
итого получается команда
chmod 3771 /folder
или
cmod u=srwx g=srwx o=tx /folder
Спасибо, очень наглядная статья, однако я бы всетаки добавил в табличку “соответствия числового (двоичного и десятичного) значения прав доступа и буквенного” столбец с “6”: rw- = 420 = 6 , больно распространенная циферка
Пожалуйста. Добавил шестерку в виде текста.
Спасибо за ваш блог. У вас явный талант учителя. Увы, но в этой статье есть неточность по поводу umask. Согласно man umask: Это инвертированная битовая маска накладываемая на набор прав по умолчанию. Таким образом при создании файла результирующий набор бит прав доступа вычисляется как 0666 & ~umask(по битово).
т.е. при umask=0022 имеем:
~0022 -> 7755 (инверсия бит)
7755 ? 0666 ->0644 (побитовое И)
Насчет вычитания это случайное совпадение.
Vadim, спасибо за дополнение.
Действительно неточность. Со временем – дополню статью…
Пример из википедии чуть более нагляден, приведу его тут:
umask = 174
файл = 666
174 = (001 111 100)
НЕ(174) = (110 000 011)
666 = (110 110 110)
--------------
666 И НЕ(174) = (110 000 010) = 602 = (rw- --- -w-)
Спасибо большое, очень интересно пишите))
Пожалуйста, приходите еще!
Помогите советом.
Чтобы программа не выполнялась от root, то нужно сделать ее владельцем обычную учетку.
Если эта учетка будет иметь значения umask 0277 (или 677) – комфортно ли будет работать с программой-браузер? Условие – обычный просмотр без скачкавания.
Чтобы программа не выполнялась от root, необходимо ее запустить не от root пользователя. А для этого у этого не-root пользователя должны быть соответствующие права на исполнение данного исполняемого файла.
Про umask трудно что-либо прокомментировать, т.к. непонятно куда эта программа будет обращаться.
Посоветуйте ресурсы и книги для изучения и понимания ACL в Windows NT. Заранее СПАСИБО!
Очень хороший материал описан тут http://www.intuit.ru/studies/courses/10471/1078/info
Спасибо большое. У Вас талант излагать сложные темы доступным для понимания образом
Один из лучших материалов по правам на файлы/папки в линукс… И, что важно – “сразу к телу”, а не “откуда началось мироздание”… Причем, сначала – самое используемое (которого в большинстве случаев достаточно), затем – углубление – для тех, кому нужно… Короче – статья – класс! Спасибо, дарагой таварисч… Привет от Странника
Вероятно, в начале статьи будет уместно такое упоминание:
“Первый символ обозначает тип данных.
Данный символ (в большинстве случаев) будет следующим:
– обычный файл;
d директория/каталог/папка (directory);
l символическая ссылка (link).”
об этом написано ниже )
Спасибо! Очень хорошее объяснение!
Подскажите, пожалуйста, как сделать так, чтобы при создании файла UID у него был не от создавшего его пользователя а другой, заданный по умолчанию. (Мне надо чтобы пользователь мог создать/положить файл в каталог, а удалить его уже не мог.)
Какие на данный момент права на фалы в каталоге и на сам каталог?
доступен на чтение для всех пользователей в системе, поэтому хранить в нём пароли (в виде хэш-сумм или как-то иначе) небезопасно. Вместо этого в Arch Linux используются shadow-пароли : поле