Unix|Linux всё о правах доступа к файлам
Во время работы с консолью в Linux вы, скорее всего, замечали сообщение об ошибке Permission denied (Отказано в доступе). Права доступа, связанные с файлами и каталогами, были разработаны для защиты важных системных файлов, а также для того, чтобы пользователи не могли получить доступ к личным файлам других пользователей.
Существует девять бит (флагов) прав доступа: первые три определяют права для владельца, следующие три — права для основной группы пользователя, а последние три — для всех остальных пользователей в системе. Для файлов флаг 'r' обозначает право на чтение файла, 'w' разрешает запись в файл, 'x' позволяет исполнить файл. Если вместо буквы указан дефис '-', это означает, что для соответствующего бита чтения, записи или исполнения право доступа отключено.
Девять основных флагов прав доступа, могут быть представлены в десяти(иногда одинадцати) символах, все вместе выглядят примерно так: -rwxrwxrwx(.|+). Именно эти символы и указывают системе: кто может читать, записывать или исполнять файл. О первом спец. символе, что определяет тип файла, и возможный последний '.' или '+', мы тоже поговорим в этой статье.
Linux следует стандартам POSIX, что делает его UNIX-совместимой операционной системой. В общем случае права доступа в UNIX разбиты на четыре категории:
u(user)—владелец файла; g(group)—группа владельца; o(other)—остальные; a(all)—просто все, как и ugo;
Соответственно каждая из этих категорий имеет по три вида следующих прав (что в совокупности образует девять флагов для каждого файла):
r(read)–чтение; w(write)–изменение; x(execute)–выполнение;
Причём эти права имеют небольшие смысловые отличия для файлов и каталогов.
Для файлов: | Для каталогов: |
|
|
Традиционная безопасность в Linux, наследованная от Unix, использует избирательное управление доступом (Discretionary Access Controls, DAC)
Unix/Linux системы изначально создавались как многопользовательские OS. В которых на одной машине одновременно может работать не один, а сразу несколько пользователей. Для этого предусмотрен (DAC) простой и хорошо продуманный механизм защиты данных, основанный на "правах доступа" к файлам (file permissions). В задачи этого механизма, входит разделение зон ответственности и одновременно надёжная защита пользовательских файлов от посторонних посягательств. Это позволяет отдельным пользователям иметь исключительные права на личные файлы и каталоги.
Если вы ещё не читали статью о пользователях и группах пользователей, с которой можно ознакомиться здесь. То для понимания "от куда растут ноги", знайте, что при создании каждый пользователь в системе имеет свой уникальный идентификационный номер (user-ID, или UID). При этом пользователи могут объединяться в общие группы, которые в свою очередь имеют group-ID, или GID.
Unix отслеживает не символьные имена владельцев и групп, а их идентификаторы (UID - для пользователей и GID для групп). Эти идентификаторы хранятся в файлах /etc/passwd и /etc/group соответственно.
Каждый пользователь входит в минимум одну группу. Группа, присваиваемая пользователю при его создании, называется основной. Все остальные группы, в которые будет включен пользователь, будут являться дополнительными.
• Группа пользователей может содержать некоторое количество пользователей, но не может содержать или включаться в другие группы.
• Группа может быть пустой, т.е. не содержать в себе ни одного пользователя.
Чтобы добавить пользователя в ту или иную группу, можно напрямую отредактировать файл /etc/group. Чтобы добавить в группу ещё пользователя,
просто напротив имени группы, через запятую допишите его символьное имя т.е. логин.
Чтобы узнать свой UID и GID, т.е. уникальный номер активного пользователя и номера его групп, в которых он состоит, и отдельно символьные имена этих групп, необходимо ввести команды:
id -Gn
Например, когда пользователь с именем vagrant создаёт файл в своём домашнем каталоге, то он становится владельцем файла, и только пользователи которые входят в его основную группу, имеют полный доступ к такому файлу. Все остальные будут иметь ограниченный доступ, позволяющий только читать, но не менять содержимое этого файла.
Каждый файл имеет три разновидности доступа:
- Чтение - если да, то разрешает смотреть содержимое файла хоть с помощью cat, хоть в редакторе без возможности изменения, имея только эти права, запись будет недоступна. Для каталога это право позволяет получить список файлов и каталогов, расположенных в нём командой ls; Без этих прав увидеть содержимое файла cat или каталога ls не получится.
- Запись - разрешает записывать новые данные в файл или изменять существующие, а также позволяет создавать и изменять файлы и каталоги;
- Выполнение - вы не можете выполнить программу, если у нее нет флага выполнения. Этот атрибут устанавливается для всех программ и скриптов, именно с помощью него система может понять, что этот файл нужно запускать как программу. Если речь идёт о каталоге, то выполнение значит возможность войти внутрь него с помощью команды cd или через менеджер файлов. Но без этого флага(что не очевидно) доступ к каталогу и по другим операциям становится весьма трудным и порой невозможным...
Доступ к файлам в Linux, организован системой простых и расширенных разрешений. Разрешения различают для трёх категорий:
- владелец файла(user owner). Пользователь, который его создал, только владелец или root может сменить владельца. По умолчанию владелец имеет все права на файл.
- группа владельца (group owner). Обычно это группа владельца, можно назначить и другую группу.
- и все остальные(others). Все пользователи, кроме уже указанных владельца и пользователей, входящих в группу файла
Ещё раз, владелец и группа владельцев для любого файла устанавливаются автоматически в момент создания. Ими по умолчанию становится сам пользователь, создавший этот файл, и его основная группа. Только владелец может устанавливать на свой файл любые разрешения. Он может полностью закрыть доступ, всем без исключения, в том числе, своей группе и себе. Да представьте, что даже root в таком случае не сможет внести изменения в файл, без предварительного изменения текущих разрешений, что по прежнему можно делать.
В GUI(графической среда), в менеджере файлов, кликнув правой кнопкой мыши на любом файле, выбрав свойства(properties), можно увидеть обсуждаемые вещи, во вкладке разрешения(permissions):
Но чтобы увидеть все подробности, и во всём полностью разобраться, открывается терминал и вызывается специальная утилита с указанием имени файла. Давайте посмотрим корневой каталог:
Мы специально к вызову утилиты ls добавили пару ключей -la, благодаря которым получаем полную информацию о корневом каталоге /. Например помимо "крестиков-ноликов" видим, имя пользователя и группы кому принадлежат права на эти каталоги, это root из группы root, также узнаём куда смотрят ссылки на другие каталоги. (тема символьных ссылок раскрыта в этой статье). И понаводите курсором мыши на подсвеченный фоновым цветом текст, чтобы получать подсказки
☯
Terminal:
⌕
≡
✕
[09:52:11 vagrant@centos7:~] $ ls -la / total 48 dr-xr-xr-x. 18 root root 4096 Jan 5 2016 . dr-xr-xr-x. 18 root root 4096 Jan 5 2016 .. -rw-r--r-- 1 root root 0 Feb 24 2015 .autorelabel lrwxrwxrwx 1 root root 7 Jan 4 2016 bin -> usr/bin dr-xr-xr-x. 5 root root 4096 Nov 16 07:37 boot drwxr-xr-x 21 root root 3220 Nov 16 21:22 dev drwxr-xr-x. 151 root root 8192 Nov 16 21:22 etc drwxr-xr-x. 3 root root 20 Aug 12 2015 home lrwxrwxrwx 1 root root 7 Jan 4 2016 lib -> usr/lib lrwxrwxrwx 1 root root 9 Jan 4 2016 lib64 -> usr/lib64 drwxr-xr-x. 3 root root 37 Jan 4 2016 media drwxr-xr-x. 2 root root 6 Aug 12 2015 mnt drwxr-xr-x. 6 root root 111 Sep 25 15:20 opt dr-xr-xr-x 157 root root 0 Nov 16 21:21 proc dr-xr-x---. 6 root root 4096 Nov 16 08:53 root drwxr-xr-x 39 root root 1180 Nov 17 01:51 run lrwxrwxrwx 1 root root 8 Jan 4 2016 sbin -> usr/sbin drwxr-xr-x. 2 root root 6 Aug 12 2015 srv dr-xr-xr-x 13 root root 0 Nov 17 07:27 sys drwxrwxrwt. 60 root root 8192 Nov 17 06:49 tmp drwxr-xr-x. 13 root root 4096 Jan 4 2016 usr drwxr-xr-x 2 root root 6 Jan 4 2016 vagrant drwxr-xr-x. 23 root root 4096 Nov 16 21:21 var [09:52:24 vagrant@centos7:~]ls -la /dev сrw-rw-rw- 1 root root 1, 3 Nov 23 08:04 null ... brw-rw---- 1 root disk 7, 1 Nov 23 08:04 loop1 ... [09:52:24 vagrant@centos7:~] info ls What\ information
☯ Сначала (DAC) об основных разрешениях: абсолютное представление прав 664 и относительное rw-rw-r--
☯ Следующим рассмотрим разрешения расширенные SUID, SGID и Sticky bit
☯ Подробно разберёмся в списках контроля доступа (ACL), чтобы создавать любые виды разрешений, сразу нескольким разным группам, на один и тот же объект (drwxr-xr-x+)
☯ В итоге будет SELinux, инструмент повышенной безопасности в Linux, с помощью управления доступом на основе ролей (RBACs) к субъектам и объектам, они же процессы и ресурсы (drwx------.)
Расшифровка всех атрибутов файла, для полного понимания механизма избирательного управления доступом (Discretionary Access Controls, DAC)
В UNIX-подобных операционных системах существует 7 типов файлов, которым соответствуют следующие аббревиату́ры: (-), (d),(p), (l), (c или b), (s), (D). Что они значат обсудим позже, этот первый символ всегда держим в уме отдельно от прав, т.е. от следующих девяти символов, чтобы не запутаться.
Следующие аббревиату́ры - биты, соответствуют правам на файл, они представленны в символьном виде. Каждый из этих битов соответствует определённому числу(в восьмеричной системы счислений) (r)(w)(x) = (4)(2)(1) = (read)(write)(execute). Поэтому данную запись прав в unix подобных os можно изменять двумя способами. Представление с помощью символов называют относительным, а с помощью чисел называют абсолютным. Чуть позже мы будем рассматривать процесс смены прав, там и поймём, логику этих названий, а пока разберёмся основательнее.
Первые десять символов, на каждой строчке, которые по началу, могут напоминать игру в "крестики нолики", это и есть вся нужная нам информация по обсуждаемой теме. На самом деле когда вы посмотрите на это со знанием дела, то всё это выглядит удобно и ясно.
Когда мы видим вначале строки, например вот это drwxrwxr-x, то представляем в уме таблицу, в том же порядке, слева направо. Причём первый символ это всегда тип данного файла, а остальные 9 это права на него. И сразу обратите внимание, что нижняя строка предствлена в виде числовых кодов(из восьмеричной системы), которые образуются из двоичной системы. Для понимания, преобразуем в уме обсуждаемую запись rwx rwx r-x в двоичный вид. Там где есть символ на месте трёх бит, то это 1, если нет (-),то 0. В итоге получаем в двоичном виде 111 111 101. Что соответствует 775
type (тип файла) | user owner права владельца u | group owner права группы g | others права остальных o |
d | rwx | rwx | r-x |
каталог(d) | (r) + (w) + (x) (100)+(010)+(001) 4 + 2 + 1 | (r) + (w) + (x) (100)+(010)+(001) 4 + 2 + 1 | (r) + (-) + (x) (100)+(000)+(001) 4 + 0 + 1 |
каталог | (111) 7 | (111) 7 | (101) 5 |
Проще говоря у такого каталога права соответствуют коду 775. Понимание, как получается этот код, нам пригодится, потому что с помощью этих кодов в восьмеричном счислении меняют и устанавливают нужные права, в абсолютном режиме.
Приведём сразу несколько примеров:
Аббревиату́ра (относительный вид) символьный | Числовой код (абсолютный вид) восьмеричные числа | Значение |
drwxrwxr-x | 775 | Собственник файла может читать, изменять и исполнять файл. Пользователи группы аналогично могут читать, изменять и исполнять этот файл, и только все другие пользователи могут только читать и исполнять этот файл. К слову сказать, каталог это исполняемый файл, ведь когда мы на него нажимаем Enter он выполняет действие, т.е. показывает своё содержимое, меняет директорию... |
-rwxr-xr-x | 755 | Собственник файла может читать, изменять и исполнять файл. Пользователи группы и все другие пользователи могут читать и исполнять этот файл. |
-rw-rw---- | 660 | Собственник файла и пользователи его группы могут читать и изменять файл. Никакие другие пользователи не имеют доступа к файлу. |
-rw------- | 600 | Собственник файла может читать и изменять файл. Никакие другие пользователи не имеют доступа к файлу. |
-rwxrwxrwx | 777 | Абсолютно все пользователи имеют право на чтение, запись и исполнение такого файла. |
Теперь когда всё понятно ещё раз посмотрим чтобы понять всё, или запомнить как мы запоминали "таблицу умножения" в школе:
результат суммы прав | восьмеричный вид(число) | двоичный вид(биты) | символьный вид | Значение | 7 | 4 + 2 + 1 | 111 | rwx | (r), (w), (x) чтение, запись, исполнение |
---|---|---|---|---|
6 | 4 + 2 + 0 | 110 | rw- | (r), (w), (-) чтение,запись, ничего |
5 | 4 + 0 + 1 | 101 | r-x | (r), (-), (x) чтение, ничего, исполнение |
4 | 4 + 0 + 0 | 100 | r-- | (r), (-), (-) чтение, ничего,ничего |
3 | 0 + 2 + 1 | 011 | -wx | (-), (w), (x) ничего,запись,исполнение |
2 | 0 + 2 + 0 | 010 | -w- | (-), (w), (-) ничего, запись, ничего |
1 | 0 + 0 + 1 | 001 | --x | (-), (-), (x) ничего, ничего, исполнение |
0 | 0 + 0 + 0 | 000 | --- | (-), (-), (-) ничего,ничего,ничего |
777 | 4+2+1 4+2+1 4+2+1 | 111 111 111 | rwx rwx rwx | (r), (w), (x) чтение, запись, исполнение (r), (w), (x) чтение, запись, исполнение (r), (w), (x) чтение, запись, исполнение |
Осталось только уточнить на счёт всех существующих типов файла, первый символ в аббревиату́ре атрибутов файла при выводе команды ls -la, чтобы картинка стала более полной. В UNIX-подобных операционных системах существует 7 типов файлов, которым соответсвуют следующие аббревиату́ры: (-), (d),(p), (l), (c или b), (s), (D)
символ | наименование | значение |
- | обычный файл (англ. regular file) | Файл - именованная область данных на носителе информации. Абстракция, используемая как базовый объект для удобства взаимодействия с данными в операционных системах. |
d | каталог (англ. directory) | Объект в файловой системе, упрощающий организацию файлов. Каталог реализован как специальный файл, где регистрируется информация о других файлах и каталогах на носителе информации. |
p | именованный канал (англ. named pipe) | Файл FIFO (First-In, First-Out — первым пришел, первым обслужен) — это канал, у которого есть имя в файловой системе. В программировании именованный канал или именованный конвейер (англ. named pipe) — один из методов межпроцессного взаимодействия, расширение понятия конвейера в Unix и подобных ОС. Именованный канал позволяет различным процессам обмениваться данными, даже если программы, выполняющиеся в этих процессах, изначально не были написаны для взаимодействия с другими программами. |
l | символическая ссылка (англ. soft link) | Символическая («мягкая») ссылка (также «симлинк», от англ. Symbolic link) — специальный файл в файловой системе, в котором вместо пользовательских данных содержится путь к файлу, открываемому при обращении к данной ссылке (файлу). |
c | файл символьного устройства (англ. device file) | Специальные файлы устройств содержат данные, необходимые операционной системе для взаимодействия с физическими устройствами, (character device) — вид файла устройства в UNIX/Linux-системах, обеспечивающий интерфейс к устройству, реальному или виртуальному, с возможностью посимвольного обмена информацией |
b | файл блочного устройства (англ. device file) | Специальные файлы устройств содержат данные, необходимые операционной системе для взаимодействия с физическими устройствами, (block device) — вид файла устройств в UNIX/Linux-системах, обеспечивающий интерфейс к устройству, реальному или виртуальному, в виде файла в файловой системе. С блочным устройством обеспечивается обмен данными блоками данных. Типичные примеры блочных устройств: жёсткий диск, CD-ROM, НГМД. |
s | сокет (англ. socket) | Со́кет (англ. socket — разъём) — название программного интерфейса для обеспечения обмена данными между процессами. Сокет — абстрактный объект, представляющий конечную точку соединения. |
D | дверь (англ. door) | механизм межпроцессного взаимодействия, используемый в ряде операционных систем семейства Unix, разновидность функционального вызова. |
Как менять права доступа к файлам:
Для начала стоит знать, что не все ваши тома, что смонтированы в системе по умолчанию поддерживают DAC. В первую очередь это касается "не родных" для linux файловых систем, таких как: ntfs и fat32?, exFat?
Если вы планируете менять основные права доступа на родных файловых системах, то пропустите этот абзац, иначе сделайте вот, что:
Например вот, таким образом следует добавить/изменить строку для раздела NTFS в файле /etc/fstab
☯
Terminal:
⌕
≡
✕
[ramanzes@fedora ~]$ cat /etc/fstab # change the "UUID" to your partition UUID # # /etc/fstab # Created by anaconda on Tue Jul 13 22:36:34 2021 UUID=XXXXXX-XXXX-XXXX-XXXX-XXXXXXXX1 / btrfs subvol=root00,compress=zstd:1 0 0 UUID=XXXXXX-XXXX-XXXX-XXXX-XXXXXXXX2 /boot ext4 defaults 1 2 UUID=XXXXXX-XXX3 /boot/efi vfat umask=0077,shortname=winnt 0 2 UUID=XXXXXX-XXXX-XXXX-XXXX-XXXXXXXX4 none swap defaults 0 0 UUID=XXXXXXXXXXXXXX5 /mnt/c ntfs defaults,auto,users,permissions 0 2 UUID=XXXXXXXXXXXXXX6 /mnt/d ntfs defaults 0 2
Опции которые мы добавили для раздела ntfs в этот файл /etc/fstab:
- auto автоматически монтируют раздел при загрузке
- users позволяют пользователям монтировать и размонтировать
- permissions принудительно включает поддержку DAC для этой файловой системы.
утилита "umask":
Настройка прав доступа в linux. "umask" (от англ. user file creation mode mask - маска режима создания пользовательских файлов)
Cамый ограниченный в этом плане, по своему функционалу, инструмент "маска" - утилита umask. Её действие не распространяется на уже существующие файлы, но применив её можно изменить "маску" прав для вновь создаваемых файлов и каталогов, в текущем каталоге. При этом, любые изменения маски с помощью этой утилиты, действуют только в текущей сессии терминала, и за пределами этого терминала, команда не имеет смысла.
При отстутствии дополнительных, расширенных настроек прав механизма DAC, для всех вновь создаваемых объектов создаются
права доступа, по умолчанию.
Для этого существует своебразная маска прав, узнать её можно с помощью команды:
Когда в стандартном каталоге пользователя, создаётся файл этим же пользователем, то файлу по умолчанию назначаются
права доступа rw-rw-r--. Каталогу назначаются права доступа rwxrwxr-x.
Для файлов и каталогов создаваемые суперпользователем действует другая маска, и права доступа к его файлам, и каталогам
выглядят так: rw-r--r-- и rwxr-xr-x соответственно.
Введите команду umask без ключей, чтобы увидеть её действующее значение в текущем каталоге, от текущего пользователя, например:
☯
Terminal:
⌕
≡
✕
[usver@fedora ~]$ umask 0002 [ramanzes@fedora ~]$ umask -S u=rwx,g=rwx,o=rx [usver@fedora ~]$ sudo su [sudo] password for usver: [root@fedora usver]# umask 0022 [root@fedora ramanzes]# umask -S u=rwx,g=rx,o=rx
Маска 0002 это тоже самое, что и 002, а маска 0022 значит 022. Т.е. нас интересует только три её крайние цифры, но суть не в этом, как это работает? Очень просто, достаточно запомнить одно главное условие:
Максимально возможные значения прав, которые можно устанавливать с помощью маски(umask), отличаются для файлов и каталогов.
И в абсолютном представлении равны следующим значениям:
На файлы:
666
(Это условие исключает случайное создание исполняемых файлов, по умолчанию.)
На каталог:
777
(Ведь каталоги для того и каталоги, чтобы быть исполняемыми, т.е. открываться клавишой Enter.)
Это в абсолютном(восьмеричном), а не в символьном(rwx) представлении.
Итак если установленная в каталоге маска у обычного пользователя равна 002, как в примере с терминалом выше, то для файлов мы получаем следующие значение действующих прав 666-002=664(rw-rw-r--), а для каталогов 777-002=775(rwxrwxr-x); Если проще то, от возможного максимума, отнимается значение установленной маски. Если смотреть на эту картину по битам, то мы получаем двоичные числа, и на месте единиц(1), соответствующие биты сбрасываются и отключают права. Смотрите таблицу:
ФАЙЛ для umask | |||||||||||
Категория прав |
User |
Group |
Other |
||||||||
Максимальные права umask в восьмеричном виде | 6 | 6 | 6 | ||||||||
Текущие права, с учётом маски. в восьмеричном виде |
6 | 6 | 4 | ||||||||
Буквенное обозначение | r | w | r | w | r | - | |||||
Битовая umask | 0 | 0 | 0 | 0 | 0 | 1 | |||||
umask в восьмеричном виде | 0 | 0 | 2 |
КАТАЛОГ | |||||||||||
Категория прав |
User |
Group | Other | ||||||||
Максимальные права umask в восьмеричном виде | 7 | 7 | 7 | ||||||||
Текущие права, с учётом umask. в восьмеричном виде |
7 | 7 | 5 | ||||||||
Буквенное обозначение | r | w | x | r | w | x | r | - | x | ||
Битовая umask | 0 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | ||
umask в восьмеричном виде | 0 | 0 | 2 |
Соответственно для суперпользователя с маской 022, права на создаваемые файлы будут 666-022=644, а на каталоги 777-022=755; Поэтому этим инструментом невозможно задать маску на создание исполняемых файлов...
имея, максимально возможные права
лишь с нулевой маской 000, для каталогов это будет 777-000=777, а для файлов это 666-000=666.
Но как устанавливать флаг на исполнение файла, мы ещё поговорим, уже в следующем абзаце посвящённому утилите chmod.
Чтобы установить новую маску для каталога достаточно при вызове утилиты umask указать желаемую маску.
Сдеалать это можно как в символьном представлении (a,u,g,o)(=+-)(rwx), так и в восьмеричном, с помощью рассмотренных выше чисел.
Синтаксис этой команды следующий:
или
$ umask опции [(a=права), u=права,g=права,o=права]
Параметр [маска] позволяет задать новую маску прав, которая будет учитываться при создании файла или каталога.
А сейчас в качестве закрепления материала, рассмотрим немного примеров, изменения действующей маски.
☯
Terminal:
⌕
≡
✕
[08:09:38 vagrant@centos7:~] $ mkdir forumask [08:09:54 vagrant@centos7:~] $ cd forumask [08:36:00 vagrant@centos7:~/forumask] $ umask 0002 [08:10:57 vagrant@centos7:~/forumask] $ touch file01 [08:11:11 vagrant@centos7:~/forumask] $ mkdir dir01
[08:12:15 vagrant@centos7:~/forumask] $ umask 777 [08:12:15 vagrant@centos7:~/forumask] $ umask a= [08:12:15 vagrant@centos7:~/forumask] umask u=,g=,o=
[08:12:28 vagrant@centos7:~/forumask] $ mkdir dir02 [08:12:40 vagrant@centos7:~/forumask] $ touch file02 [08:37:06 vagrant@centos7:~/forumask] $ umask 0777 [08:12:47 vagrant@centos7:~/forumask] $ ls -la total 4 drwxrwxr-x 4 vagrant vagrant 56 Dec 15 08:12 . drwx------. 22 vagrant vagrant 4096 Dec 15 08:09 .. drwxrwxr-x 2 vagrant vagrant 6 Dec 15 08:12 dir01 d--------- 2 vagrant vagrant 6 Dec 15 08:12 dir02 -rw-rw-r-- 1 vagrant vagrant 0 Dec 15 08:12 file01 --------- 1 vagrant vagrant 0 Dec 15 08:12 file02
[09:33:16 vagrant@centos7:~/forumask] $ umask 022 [09:33:26 vagrant@centos7:~/forumask] $ umask 0022 [09:33:33 vagrant@centos7:~/forumask] $ umask -S u=rwx,g=rx,o=rx [09:33:35 vagrant@centos7:~/forumask] $ umask u=rwx,g=rx,o=rx [09:34:06 vagrant@centos7:~/forumask] $ umask 0022 [09:34:04 vagrant@centos7:~/forumask] $ umask -S u=rwx,g=rx,o=rx [09:46:03 vagrant@centos7:~/forumask] $ mkdir dir03 [09:46:08 vagrant@centos7:~/forumask] $ touch file03 [09:46:20 vagrant@centos7:~/forumask] $ ls -la total 4 drwxrwxr-x 5 vagrant vagrant 81 Dec 15 09:46 . drwx------. 22 vagrant vagrant 4096 Dec 15 08:09 .. drwxrwxr-x 2 vagrant vagrant 6 Dec 15 08:12 dir01 d--------- 2 vagrant vagrant 6 Dec 15 08:12 dir02 drwxr-xr-x 2 vagrant vagrant 6 Dec 15 09:46 dir03 -rw-rw-r-- 1 vagrant vagrant 0 Dec 15 08:12 file01 ---------- 1 vagrant vagrant 0 Dec 15 08:12 file02 -rw-r--r-- 1 vagrant vagrant 0 Dec 15 09:46 file03
[09:53:32 vagrant@centos7:~/forumask] $ $ mkdir -m=777 dir04 [09:53:03 vagrant@centos7:~/forumask] $ ls -la total 4 drwxrwxr-x 6 vagrant vagrant 93 Dec 15 09:53 . drwx------. 22 vagrant vagrant 4096 Dec 15 08:09 .. drwxrwxr-x 2 vagrant vagrant 6 Dec 15 08:12 dir01 d--------- 2 vagrant vagrant 6 Dec 15 08:12 dir02 drwxr-xr-x 2 vagrant vagrant 6 Dec 15 09:46 dir03 drwxrwxrwx 2 vagrant vagrant 6 Dec 15 09:53 dir04 -rw-rw-r-- 1 vagrant vagrant 0 Dec 15 08:12 file01 ---------- 1 vagrant vagrant 0 Dec 15 08:12 file02 -rw-r--r-- 1 vagrant vagrant 0 Dec 15 09:46 file03 [09:54:14 vagrant@centos7:~/forumask] $ umask 0022
#Если с числовой формой создания маски всё ясно, какое число такая и маска, то символьный способ задания маски схож с #синтаксисом команды chmod, подробнее о которой, мы поговорим в следующем блоке этой статьи, а пока приведём ещё #несколько примеров:
#Группы прав можно объединять, или же задавать права сразу для всех категорий, использовав параметр a= (all). [22:26:45 vagrant@centos7:~/forumask] $ umask ug=rwx,o=rx [22:26:54 vagrant@centos7:~/forumask] $ umask 0002 [22:26:57 vagrant@centos7:~/forumask] $ umask -S u=rwx,g=rwx,o=rx [22:26:59 vagrant@centos7:~/forumask] $ umask a=rwx [22:27:04 vagrant@centos7:~/forumask] $ umask 0000 [22:27:07 vagrant@centos7:~/forumask] $ umask -S u=rwx,g=rwx,o=rwx #Можно работать с отдельными правами. #Оператором - можно запретить определённое действие, остальные биты в маске останутся нетронутыми. [22:27:08 vagrant@centos7:~/forumask] $ umask ug-w [22:27:16 vagrant@centos7:~/forumask] $ umask 0220 [22:27:17 vagrant@centos7:~/forumask] $ umask -S u=rx,g=rx,o=rwx #Оператором + можно разрешить определённое действие, остальные биты в маске останутся нетронутыми. [22:27:18 vagrant@centos7:~/forumask] $ umask a+w [22:27:24 vagrant@centos7:~/forumask] $ umask 0000 [23:22:46 vagrant@centos7:~/forumask] $ umask -S u=rwx,g=rwx,o=rwx [22:27:25 vagrant@centos7:~/forumask] $ umask u=rwx,go-r [22:27:33 vagrant@centos7:~/forumask] $ umask 0044 [22:27:40 vagrant@centos7:~/forumask] $ umask -S u=rwx,g=wx,o=wx
Промежуточный итог по утилите "umask" перед рассмотрением утилиты "chmod":
Действие утилиты umask ограничено по времени, т.е. работает в пределах одной сессии терминала, и не распространяется на всю систему и другие сессии.
Если нужно навсегда изменить значение маски по умолчанию, измените значение umask на нужное вам в файле:
измените umask внутри скрипта bash или просто добавьте новую строку в конце файла,
с нужной вам маской, например вот такой: umask 000.
Чтобы изменения вступили в силу, выйдите из сеанса системы, и снова войдите. Или
выполните следующую source команду (без sudo)
В следующий раз, когда вы запустите оболочку, umask будет действовать в установленном значении. В некоторых дистрибутивах, эту настройку задают в других файлах: ~/.bashsrc или /etc/bash.bashsrc.
Изменение маски для всех программ системы – многоуровневая задача, которая потребует внесение множества правок. Поэтому вместо этого используют списки ACL, установленные командой setfacl, но об этом чуть позже, после рассмотрения понятия расширенных прав.
Перед тем как рассматривать более мощную утилиту "chmod" после рассмотрения "umask", учтите три значительных отличия.
- umask задаёт маску только для вновь создаваемых файлов, а chmod устанавливает и меняет права ещё, и для уже существующих файлов/каталогов.
- если говорить о маске, то у umask она инверсная т.е. чем больше устанливаемое восьмеричное число 777(абсолютный вид) тем меньше прав. В то время как у chmod будет наоборот чем меньше устанавливаемое восьмеричное число тем меньше прав...
- umask не может предоставить права на выполнение файла. Даже если указать максимально возможную маску 000, разрешающую всё, то для файла будут заданы права rw-rw-rw-. В то время как у команды chmod таких ограничений нет.
- Действие утилиты umask весьма ограничено, т.е. работает в пределах одной сессии текущего терминала, и не распространяется на всю систему и другие сессии. Установленные же права с помощью chmod действуют сразу во всей системе, и сохраняются в ней навсегда, независимо от сессии.
В качестве общего утилит umask и chmod можно отметить общую логику восьмеричного(абсолютного) представления прав, и аналогичный символьный(относительный) синтаксис предоставления прав через операторы =, +, -. Также обе эти команды не способны менять владельца и группу, для этого существуют утилиты "chown" и "chgrp" представленные в другом разделе.
резюме:
Утилита umask в unix существует для установки маски прав, для вновь создаваемых файлов и каталогов.
Она используется для задавания прав заранее перед их созданием. Но все изменения маски действуют
только в текущей сессии терминала. За пределами активного терминала, утилита не имеет практического применения.
утилита "chmod":
Команда chmod используется для установки прав доступа к файлу, производное сокращение от change mode (изменения режима). Только собственник файла(или root) может изменять права на файл. Синтаксис команды chmod:
Как и было сказано вначале можно пользоваться двумя способами с помощью числовых кодов(это абсолютный режим) или с помощью символов rwx(относительный режим). Рассмотрим оба способа по очереди, как получать числовой код думаю вам ясно, если же нет, то ещё раз смотрите в таблицах выше.
С точки зрения компьютерной логики, абсолютный способ установки прав соответствует операции присвоения переменной новых значений, что является полной заменой всех существующих на данный момент прав на файл. В то время как относительный способ, сродни операциям инкремента или декремента, если вы используете в команде ключи (+) и (-). Т.е. когда выбранные символы прав добавляются или отнимаются от уже существующих на данный момент значений, т.е. не заменяя полностью исходное значение, как в первом случае... Однако если вы подставите ключ (=), то это тоже будет присвоением новых прав - с полной заменой всех существующих, почти как с абсолютным способом, но с не большим отличием: только права расширенного флага, так всё-равно не "затрутся", если их явно не указали в команде.
Синтаксис команды прост:
chmod <опции> <права> <объект или регулярное выражение>
Из самых полезных и часто используемых опций можно выделить одну:
-R - рекурсивное назначение прав. Т.е. назначить права всем объектам, руководствуясь регулярным выражением.
остальные можно узнать из chmod --help
Подробный синтаксис абсолютного способа (восьмеричные коды):
chmod<опции>доп. бит для расширенных правКОД ИЗ ТРЁХ ЧИСЕЛ filename
Синтаксис, относительного способа (специальные символы):
chmod<опции>{a,u,g,o}{+,-,=}{r,w,x}{s,t} filenames
Сначала после имени команды вы ставите один или несколько из следующих символов: a (сокращение от all — все), u (сокращение от user owner — владелец), g (сокращение от group owner — группа владельца), или o (сокращение от other — прочие). Затем вы точно определяете, добавляете ли вы права (+) или убираете (-), или присваиваете (=). После, вы пишете один или сразу несколько символов из следующего набора: r (сокращение от read — чтение), w (сокращение от write — запись), x (сокращение от execute — исполнение). И в конце имя файла к которому применяется эта операция.
Чтобы увидеть обсуждаемое выполним эти два способа, двумя, почти идентичными командами(главные различия этих способов станут совсем очевидными, когда мы поговорим об расширенных правах). Но в данном случае, для усвоения материала, результат будет совершенно идентичен:
chmod a=rwx filename
Посмотрим это дело на практике, создадим каталог для тестов и два файла, которым изменим права и убедимся в этом:
☯
Terminal:
⌕
≡
✕
[05:31:26 vagrant@centos7:~] $ mkdir ~/test [05:31:54 vagrant@centos7:~] $ cd ~/test [05:32:11 vagrant@centos7:~/test] $ touch f1.txt [05:33:31 vagrant@centos7:~/test] $ touch f2.txt [05:37:14 vagrant@centos7:~/test] $ ls -la total 4 drwxrwxr-x 2 vagrant vagrant 32 Nov 29 05:37 . drwx------. 19 vagrant vagrant 4096 Nov 29 05:31 .. -rw-rw-r-- 1 vagrant vagrant 0 Nov 29 05:33 f1.txt -rw-rw-r-- 1 vagrant vagrant 0 Nov 29 05:37 f2.txt
[05:46:05 vagrant@centos7:~/test] $ chmod 777 f1.txt [06:06:42 vagrant@centos7:~/test] $ ls -l total 0 -rwxrwxrwx 1 vagrant vagrant 0 Nov 29 05:33 f1.txt -rw-rw-r-- 1 vagrant vagrant 0 Nov 29 05:37 f2.txt [07:16:11 vagrant@centos7:~/test] $ chmod a=rwx f2.txt [07:16:48 vagrant@centos7:~/test] $ ls -l total 4 -rwxrwxrwx 1 vagrant vagrant 7 Nov 29 06:06 f1.txt -rwxrwxrwx 1 vagrant vagrant 0 Nov 29 07:16 f2.txt
смотрите наш пустой файл стал исполняемым, давайте запишем в него команду и выполним его для проверки... [07:17:48 vagrant@centos7:~/test] $ echo "ls -la" > f1.txt [07:18:00 vagrant@centos7:~/test] $ cat f1.txt ls -la [07:18:03 vagrant@centos7:~/test] $ ./f1.txt total 8 drwxrwxr-x 2 vagrant vagrant 32 Nov 29 06:08 . drwx------. 19 vagrant vagrant 4096 Nov 29 06:08 .. -rwxrwxrwx 1 vagrant vagrant 7 Nov 29 06:10 f1.txt -rwxrwxrwx 1 vagrant vagrant 0 Nov 29 07:16 f2.txt действительно так и обстоят дела на самом деле.... текстовый файл передал интерпретатору bash выполнить записанную в него команду.
В указанном примере, мы создали каталог test в домашнем каталоге, вывод ls с ключом -la, отображает установленые на текущие файлы и каталоги права.
Любые права установленные на каталог это важно, по причине наследования этих прав, у вновь создаваемых файлов и каталогов внутри него.
Имя файла, с символом точки (.), соответствует здесь текущему каталогу, а имя файла, с двумя символами точки (..) - родительскому. Имена двух других файлов мы создали здесь сами.
Права на каталоги
Когда речь заходит о правах на каталоги, появляются некоторые отличия. Каталоги используют те же флаги прав доступа, что и файлы, но их интерпретация порой не совсем очевида... Но как говорят: "повторение мать учения".
Если для каталога задан флаг чтения, то вы можете просматривать список содержимого каталога; флаг записи означает, что вы можете
создавать файлы внутри этого каталога; и флаг исполнения означает, что вы можете войти в каталог и обращаться ко всем подкаталогам внутри.
Без флага исполнения у вас не будет доступа к объектам файловой системы внутри каталога, и вообще доступ к каталогу будет весьма "странным" даже с флагом r... с помощью ls сможем увидеть только имена файлов и ничего больше, про флаг w в таком случае можно не вспоминать, разберём в примерах после рассмотрения расширенных прав.
Без флага чтения объекты файловой системы внутри каталога нельзя просмотреть, но к объектам внутри него всё еще можно обратиться, если вы знаете полный путь к объекту на диске и его имя.
С флагом записи w, в каталоге можно будет создавать новые каталоги и файлы, только если не сброшен дефолтный флаг исполнения x.
Стоит сразу добавить, чтобы массово установить права на определённый тип объектов, используют регулярные выражения, можно использовать один из множества вариантов
(вообще, их очень много):
Если вы не желаете случайно поменять и биты расширенных прав, тогда лучше использовать относительный способ, с помощью символов. В два этапа понятнеее всего. Например сначала присвоить всем все права a=rwX. Причём X именно в верхнем регистре, в данном случае это способ задать права исполнения исключительно для каталогов. Теперь забираем права на запись и исполнение, у выбраной категории, например o-wX (o)-остальные. Следующий пример делает это. В нём права применяеются сразу на все типы файлов и каталогов, рекурсивно, т.е. и в подкаталогах, потому что указан ключ -R.
sudo chmod -R o-wX ./
Есть и более скриптовые способы установки прав на выборку файлов определённого типа, например с помощью абсолютного способа т.е. с помощью цифр, в котором, обнуляются действие расширенных флагов если они были установлены... О чём ещё поговорим ниже.
где -type d - каталоги, -type f - файлы. В данном примере chmod установит, начиная от текущего каталога, права на все каталоги (включая подкаталоги ключ -R) разрешения 770 (rwx rwx ---) при этом не трогая другие объекты (в начале статьи приведены символьные значения файлов всех остальных типов).
Другой вариант выполнения аналогичной операции:
где -type d - каталоги, -type f - файлы. В данном варианте chmod установит разрешения 775 на все файлы включая файлы в подкаталогах начиная от текущего, но не на другие объекты(например каталоги, симлинки, или файлы драйверов, перечисляемые в начале этой статьи...).
☯
Terminal:
⌕
≡
✕
[22:57:43 vagrant@centos7:~/test] $ ls -la total 116 drwxrwxr-x+ 5 vagrant vagrant 4096 Dec 16 10:13 . drwx------. 24 vagrant vagrant 4096 Jan 24 13:10 .. -rw-r--r-- 1 root root 30720 Dec 9 09:20 --acls -rw-rw-rw- 1 vagrant vagrant 1322 Dec 6 06:19 file.acls -rw-rw-rw- 1 vagrant vagrant 91 Dec 3 06:14 Makefile drw-rw-r-- 2 vagrant vagrant 20 Dec 16 10:16 new_ drwxrwsr-x+ 7 root my_new 106 Dec 5 06:40 newcatalog -rw-rw-rw- 1 vagrant vagrant 1579 Dec 3 06:31 proga.c -rw-r--rw- 1 vagrant vagrant 12288 Dec 11 11:23 .proga.c.swp -rw-r--r-- 1 root root 2048 Dec 3 06:32 proga.o -rwsr-xr-x 1 root root 8753 Dec 3 06:32 program drwxrwxr-x 4 root root 40 Dec 3 06:33 speckatalog -rw-r--r-- 1 root root 30720 Dec 9 09:27 s_t_newcatalog.tar
[22:57:45 vagrant@centos7:~/test] $ chmod -R o+w $(find . -type d) find: ‘./new_/dfdf.ee’: Permission denied chmod: changing permissions of ‘./speckatalog’: Operation not permitted chmod: changing permissions of ‘./speckatalog/proba_suid’: Operation not permitted chmod: changing permissions of ‘./proga.o’: Operation not permitted chmod: changing permissions of ‘./program’: Operation not permitted chmod: changing permissions of ‘./--acls’: Operation not permitted chmod: changing permissions of ‘./s_t_newcatalog.tar’: Operation not permitted chmod: changing permissions of ‘./newcatalog’: Operation not permitted chmod: changing permissions of ‘./newcatalog/vd2’: Operation not permitted chmod: changing permissions of ‘./newcatalog/vf2’: Operation not permitted chmod: changing permissions of ‘./newcatalog/vd2_2’: Operation not permitted chmod: changing permissions of ‘./newcatalog/vd2_2/vd2_2_2’: Operation not permitted chmod: changing permissions of ‘./newcatalog/vf2_2’: Operation not permitted chmod: changing permissions of ‘./newcatalog/vd3_3’: Operation not permitted chmod: cannot access ‘./new_/dfdf.ee’: Permission denied chmod: changing permissions of ‘./speckatalog’: Operation not permitted chmod: changing permissions of ‘./speckatalog/proba_suid’: Operation not permitted chmod: changing permissions of ‘./speckatalog/proba_suid’: Operation not permitted chmod: changing permissions of ‘./newcatalog’: Operation not permitted chmod: changing permissions of ‘./newcatalog/vd2’: Operation not permitted chmod: changing permissions of ‘./newcatalog/vf2’: Operation not permitted chmod: changing permissions of ‘./newcatalog/vd2_2’: Operation not permitted chmod: changing permissions of ‘./newcatalog/vd2_2/vd2_2_2’: Operation not permitted chmod: changing permissions of ‘./newcatalog/vf2_2’: Operation not permitted chmod: changing permissions of ‘./newcatalog/vd3_3’: Operation not permitted chmod: changing permissions of ‘./newcatalog/vd2’: Operation not permitted chmod: changing permissions of ‘./newcatalog/vd2_2’: Operation not permitted chmod: changing permissions of ‘./newcatalog/vd2_2/vd2_2_2’: Operation not permitted chmod: changing permissions of ‘./newcatalog/vd2_2/vd2_2_2’: Operation not permitted chmod: changing permissions of ‘./newcatalog/vd3_3’: Operation not permitted chmod: cannot access ‘./new_/dfdf.ee’: Permission denied [23:01:35 vagrant@centos7:~/test] $ ls -la total 116 drwxrwxrwx+ 5 vagrant vagrant 4096 Dec 16 10:13 . drwx------. 24 vagrant vagrant 4096 Jan 24 13:10 .. -rw-r--r-- 1 root root 30720 Dec 9 09:20 --acls -rw-rw-rw- 1 vagrant vagrant 1322 Dec 6 06:19 file.acls -rw-rw-rw- 1 vagrant vagrant 91 Dec 3 06:14 Makefile drw-rw-rw- 2 vagrant vagrant 20 Dec 16 10:16 new_ drwxrwsr-x+ 7 root my_new 106 Dec 5 06:40 newcatalog -rw-rw-rw- 1 vagrant vagrant 1579 Dec 3 06:31 proga.c -rw-rw-rw- 1 vagrant vagrant 12288 Dec 11 11:23 .proga.c.swp -rw-r--r-- 1 root root 2048 Dec 3 06:32 proga.o -rwsr-xr-x 1 root root 8753 Dec 3 06:32 program drwxrwxr-x 4 root root 40 Dec 3 06:33 speckatalog -rw-r--r-- 1 root root 30720 Dec 9 09:27 s_t_newcatalog.tar
[23:02:55 vagrant@centos7:~/test] $ chmod -R o-w $(find . -type f) find: ‘./new_/dfdf.ee’: Permission denied chmod: changing permissions of ‘./proga.o’: Operation not permitted chmod: changing permissions of ‘./program’: Operation not permitted chmod: changing permissions of ‘./--acls’: Operation not permitted chmod: changing permissions of ‘./s_t_newcatalog.tar’: Operation not permitted chmod: changing permissions of ‘./newcatalog/vf2’: Operation not permitted chmod: changing permissions of ‘./newcatalog/vf2_2’: Operation not permitted [23:04:05 vagrant@centos7:~/test] $ ls -la total 116 drwxrwxrwx+ 5 vagrant vagrant 4096 Dec 16 10:13 . drwx------. 24 vagrant vagrant 4096 Jan 24 13:10 .. -rw-r--r-- 1 root root 30720 Dec 9 09:20 --acls -rw-rw-r-- 1 vagrant vagrant 1322 Dec 6 06:19 file.acls -rw-rw-r-- 1 vagrant vagrant 91 Dec 3 06:14 Makefile -rw-rw-rw- 2 vagrant vagrant 20 Dec 16 10:16 new_ drwxrwsr-x+ 7 root my_new 106 Dec 5 06:40 newcatalog -rw-rw-r-- 1 vagrant vagrant 1579 Dec 3 06:31 proga.c -rw-rw-r-- 1 vagrant vagrant 12288 Dec 11 11:23 .proga.c.swp -rw-r--r-- 1 root root 2048 Dec 3 06:32 proga.o -rwsr-xr-x 1 root root 8753 Dec 3 06:32 program drwxrwxr-x 4 root root 40 Dec 3 06:33 speckatalog -rw-r--r-- 1 root root 30720 Dec 9 09:27 s_t_newcatalog.tar
[23:06:50 vagrant@centos7:~/test] $ chmod -R o-w $(find . -type d) find: ‘./new_/dfdf.ee’: Permission denied chmod: changing permissions of ‘./speckatalog’: Operation not permitted chmod: changing permissions of ‘./speckatalog/proba_suid’: Operation not permitted chmod: changing permissions of ‘./proga.o’: Operation not permitted chmod: changing permissions of ‘./program’: Operation not permitted chmod: changing permissions of ‘./--acls’: Operation not permitted chmod: changing permissions of ‘./s_t_newcatalog.tar’: Operation not permitted chmod: changing permissions of ‘./newcatalog’: Operation not permitted chmod: changing permissions of ‘./newcatalog/vd2’: Operation not permitted chmod: changing permissions of ‘./newcatalog/vf2’: Operation not permitted chmod: changing permissions of ‘./newcatalog/vd2_2’: Operation not permitted chmod: changing permissions of ‘./newcatalog/vd2_2/vd2_2_2’: Operation not permitted chmod: changing permissions of ‘./newcatalog/vf2_2’: Operation not permitted chmod: changing permissions of ‘./newcatalog/vd3_3’: Operation not permitted chmod: cannot access ‘./new_/dfdf.ee’: Permission denied chmod: changing permissions of ‘./speckatalog’: Operation not permitted chmod: changing permissions of ‘./speckatalog/proba_suid’: Operation not permitted chmod: changing permissions of ‘./speckatalog/proba_suid’: Operation not permitted chmod: changing permissions of ‘./newcatalog’: Operation not permitted chmod: changing permissions of ‘./newcatalog/vd2’: Operation not permitted chmod: changing permissions of ‘./newcatalog/vf2’: Operation not permitted chmod: changing permissions of ‘./newcatalog/vd2_2’: Operation not permitted chmod: changing permissions of ‘./newcatalog/vd2_2/vd2_2_2’: Operation not permitted chmod: changing permissions of ‘./newcatalog/vf2_2’: Operation not permitted chmod: changing permissions of ‘./newcatalog/vd3_3’: Operation not permitted chmod: changing permissions of ‘./newcatalog/vd2’: Operation not permitted chmod: changing permissions of ‘./newcatalog/vd2_2’: Operation not permitted chmod: changing permissions of ‘./newcatalog/vd2_2/vd2_2_2’: Operation not permitted chmod: changing permissions of ‘./newcatalog/vd2_2/vd2_2_2’: Operation not permitted chmod: changing permissions of ‘./newcatalog/vd3_3’: Operation not permitted chmod: cannot access ‘./new_/dfdf.ee’: Permission denied [23:07:36 vagrant@centos7:~/test] $ ls -la total 116 drwxrwxr-x+ 5 vagrant vagrant 4096 Dec 16 10:13 . drwx------. 24 vagrant vagrant 4096 Jan 24 13:10 .. -rw-r--r-- 1 root root 30720 Dec 9 09:20 --acls -rw-rw-r-- 1 vagrant vagrant 1322 Dec 6 06:19 file.acls -rw-rw-r-- 1 vagrant vagrant 91 Dec 3 06:14 Makefile drw-rw-r-- 2 vagrant vagrant 20 Dec 16 10:16 new_ drwxrwsr-x+ 7 root my_new 106 Dec 5 06:40 newcatalog -rw-rw-r-- 1 vagrant vagrant 1579 Dec 3 06:31 proga.c -rw-r--r-- 1 vagrant vagrant 12288 Dec 11 11:23 .proga.c.swp -rw-r--r-- 1 root root 2048 Dec 3 06:32 proga.o -rwsr-xr-x 1 root root 8753 Dec 3 06:32 program drwxrwxr-x 4 root root 40 Dec 3 06:33 speckatalog -rw-r--r-- 1 root root 30720 Dec 9 09:27 s_t_newcatalog.tar [23:07:40 vagrant@centos7:~/test] $
Расширенные права:
Помимо сказанного, в Linux есть набор дополнительных - расширенных разрешений. Разрешения добавляются с помощью chmod путём изменения трёх продвинутых разрешений: SUID, GUID и sticky bit.
Начнём с SUID и SGID, этот вид прав предназначен исключительно для исполняемых файлов.
SUID имеет числовое(восьмеричное) значение 4 или (100 в двоичном представлении...), и если для исполняемого файла программы он установлен, то она будет работать от имени владельца этого файла, а не от имени того, кто запустил программу. (сразу добавлю, что для файлов каких либо скриптов(sh...) именно интерпритируемых языков, это не сработает, из соображений безопасности.. только на бинарные файлы).
Только представьте себе такой файл, в который можно написать любую команду и она выполнится от рута и без ввода пароля например...
SGID имеет числовое значение 2 или(010), фактически тоже самое, только он позволяет программе наследовать права на запуск от группы к которой принадлежит файл, вместо прав пользователя, который этот файл запускает в данный момент.
А sticky bit, этот вид прав, является защитой от удаления любого файла или каталога, имеет числовое значение 1 или (001). Если установлен, то единственные, кто могут удалить или переименовать такой файл — это
либо владелец этого файла, либо суперпользователь, и никто больше.
Как можно увидеть расширенные права, с теми знаниями, что мы уже рассмотрели:
Фактически это ещё один бит в числовом коде который в рассматриваемых ранее абсолютных представлениях по умолчанию был равен 0. Поэтому мы использовали три восьмеричных числа. Так например код 777 совершенно идентичен с 0-выми спец. разрешениями из 4-чисел коду 0777. Но этот первый бит может также принимать с 0 до 7 разных значений, и они все будут представлены в таблице ниже.
В относительном представлении эти права, в случае наличия таковых, видно как символ s в том месте, где должны быть права символа x - разрешающих исполнение файла. Как мы увидим тогда исполняемый этот файл или нет, если вместо x будет s? А вот как, в случае одновременного существования и прав на исполнения (x) и SUID, ставится именно (s) в нижнем регистре. Если прав на исполнения файла нет, т.е. вместо (x) был бы прочерк (-), но там установлен SUID, то ставится символ (S) в верхнем регистре.
Только какой смысл в таких прав S, если файл не исполняемый, какая разница от какого пользователя ему доступно исполнение? В линуксе разные бывают случаи, для каталога например такая ситуация может создать наследование, так что нельзя сказать, что вообще нет никакого смысла в таких правах как S, без наличия прав на исполнения... Да и к тому же кто знает для чего это может пригодиться..., возможно ведь, и добавлять, и убирать права x, получив тем самым s, по расписанию в специальном скрипте cron например, для каких нибудь неочевидных задач... Поэтому, что это: "Баг" или "Фича" уже решать вам.
Сразу стоит знать, что мало кто (из пользователей системы) целенаправленно использует бит расширенных прав, но он предоставляет собой полезное и порой незаменимое дополнение... Причём операционная система, на некоторые системные файлы/каталоги устанавливает расширенные разрешения по умолчанию. И даже только поэтому, о них определённо стоит знать. Но есть одно важное замечание: suid и sgid хоть и бывают удобны для продвинутых, однако неправильное их использование может привести к появлению уязвимостей и дыр в защите системы, и лучше избегать их использования. При этом, конечно, совсем обойтись без этого нельзя, ибо даже программа passwd например — одна из немногих, которая должна быть с установленным suid, чтобы правильно функционировать.
☯
Terminal:
⌕
≡
✕
[11:23:10 vagrant@centos7:~] $ ls -la /bin/passwd -rwsr-xr-x. 1 root root 27832 Jun 9 2014 /bin/passwd
Понимание расширенных прав SUID, SGID и sticky bit
добавляются эти права той же программой chmod совершенно идентично и по той же логике: абсолютным и относительным способом.
Установим для примера все разрешения в том числе расширенные права на файл, двумя этим способами.
В абсолютном представлении вид будет такой:
В относительном представлении будет таким:
или короче
chmod a=rwxst filename
где символ s это SUID(флаг для пользователя), SGID(для группы), и символ t установит sticky bit.
suid (флаг идентификатора пользователя) | sgid (флаг идентификатора группы) | sticky bit (защита от удаления) | включение программа chmod и аргументы | Mode (числовой код) восьмеричный вид | двоичный вид |
on | on | on | chmod 7777 filename chmod a=st filename | 7 | 111 |
on | on | off | chmod 6777 filename chmod ug=s filename | 6 | 110 |
on | off | on | chmod 5777 filename chmod u=st filename | 5 | 101 |
on | off | off | chmod 4777 filename chmod u=s filename | 4 | 100 |
off | on | on | chmod 3777 filename chmod g=st filename | 3 | 011 |
off | on | off | chmod 2777 filename chmod g=s filename | 2 | 010 |
off | off | on | chmod 1777 filename chmod u=t filename | 1 | 001 |
off | off | off | chmod 0777 filename chmod a-st filename | 0 | 000 |
Бинарный файл и флаг расширенных прав SUID
Давайте рассмотрим живой пример собственного использования SUID, чтобы любой(сильно) желающий смог понять принцип и область применения. Мы напишем для проверки, простенькую программку на Си, с единственным функционалом: это создавать каталоги с именем, которое вводит пользователь из клавиатуры.
- Мы скомпилируем её в бинарник с именем "program", от пользователя root, чтобы он стал его владельцем
- Установим флаг "sudo chmod u+s program", чтобы любой запускающий её пользователь, благодаря флагу suid, на время выполнения получал права владельца т.е. root.
- Запустим бинарник от обычного пользователя и протестируем такую возможность
Теперь внимание на первый фрейм терминала, в котором приведён код и описаны все действия по созданию нашего бинарника:
☯
Terminal:
⌕
≡
✕
#Для создания своего бинарника, для проверки прав SUID, нам нужен копмилируемый язык, пусть это будет Си #Сперва создаём наш исходный файл proga.c в удобном для вас редакторе кода, и заполняем его следующим кодом:
[12:32:24 vagrant@centos7:~/test] $ vim proga.c #include <stdio.h> // от англ. standard input/output header — стандартный заголовочный файл ввода-вывода) - заголовочный файл стандартной библиотеки языка Си #define SIZE 108 //создание константы SIZE для определния длины строки, 108 символов нам точно здесь хватит... int main(){ //начало основной программы, главной и обязательной функции в C char command[SIZE]; // объявление строковой переменной printf("Введите путь и имя создаваемого каталога:\n"); // вывод на экран информативной строки fscanf(stdin,"%[^\n]",command); //запись ввода из клавиатуры пользователя, в переменную command, всех символов, включая пробелы, до конца строки fprintf(stdout,"То, что мы ввели в переменную:%s \n",command); //вывод на экран введённой строки mkdir(command, 0770); //создать каталог с введённым именем(в переменную command), дать каталогу права 0770, т.е. весь доступ, но только владельцу и группе return 0; //стандартное завершение функции на C }
#В этом же каталоге, создаём Makefile(имя файла начинается с большой буквы), он создаётся для удобного процесса компиляции, язык C. #Который потом запустится одной командой make. У команд (2 и 4 строки) сохраняйте отступы с помощью Tab, не пробелы, #в Makefile это важно... Содержимое файла:
[12:42:24 vagrant@centos7:~/test] $ vim Makefile program: proga.o gcc -lm proga.o -o program proga.o: proga.c gcc -c proga.c -o proga.o
#Компилируем файл от имени суперпользователя sudo, одной командой make
[12:44:16 vagrant@centos7:~/test] $ sudo make gcc -c proga.c -o proga.o gcc -lm proga.o -o program
#Смотрим, и видим свой бинарник с именем program
[12:44:20 vagrant@centos7:~/test] $ ls -la total 32 drwxrwxr-x 2 vagrant vagrant 89 Dec 2 12:44 . drwx------. 20 vagrant vagrant 4096 Dec 2 12:42 .. -rwxrwxr-x 1 vagrant vagrant 17 Nov 29 08:59 f1.txt -rwxrwxr-x 1 vagrant vagrant 0 Nov 29 05:37 f2.txt -rw-rw-r-- 1 vagrant vagrant 93 Dec 2 12:34 Makefile -rw-rw-r-- 1 vagrant vagrant 713 Dec 2 12:36 proga.c -rw-r--r-- 1 root root 2048 Dec 2 12:44 proga.o -rwxr-xr-x 1 root root 8753 Dec 2 12:44 program
#Устанавливаем SUID на наш файл program
[22:10:07 vagrant@centos7:~/test] $ sudo chmod u+s program [23:53:07 vagrant@centos7:~/test] $ ls -la total 32 drwxrwxr-x 2 vagrant vagrant 89 Dec 2 22:06 . drwx------. 20 vagrant vagrant 4096 Dec 2 12:42 .. -rwxrwxr-x 1 vagrant vagrant 17 Nov 29 08:59 f1.txt -rwxrwxr-x 1 vagrant vagrant 0 Nov 29 05:37 f2.txt -rw-rw-r-- 1 vagrant vagrant 93 Dec 2 12:34 Makefile -rw-rw-r-- 1 vagrant vagrant 713 Dec 2 12:36 proga.c -rw-r--r-- 1 root root 2048 Dec 2 12:44 proga.o -rwsr-xr-x 1 root root 8753 Dec 2 12:44 program [23:53:14 vagrant@centos7:~/test] $
Теперь мы готовы к тестированию расширенных прав SUID.
- Сначала мы создадим каталог от root, в котором мы не сможем создать подкаталог от обычного пользователя, vagrant так, как не имеем прав делать запись в каталог суперпользователя.
- Но с этой программой, этим же пользователем vagrant в момент выполнения program, мы получим такую возможность, потому что знаем, что делаем...
☯
Terminal:
⌕
≡
✕
[23:53:14 vagrant@centos7:~/test] $ sudo mkdir speckatalog [00:32:11 vagrant@centos7:~/test] $ mkdir speckatalog/proba_suid mkdir: cannot create directory ‘speckatalog/proba_suid’: Permission denied [00:32:51 vagrant@centos7:~/test] $ ls -la total 32 drwxrwxr-x 3 vagrant vagrant 107 Dec 3 00:32 . drwx------. 20 vagrant vagrant 4096 Dec 2 12:42 .. -rwxrwxr-x 1 vagrant vagrant 17 Nov 29 08:59 f1.txt -rwxrwxr-x 1 vagrant vagrant 0 Nov 29 05:37 f2.txt -rw-rw-r-- 1 vagrant vagrant 93 Dec 2 12:34 Makefile -rw-rw-r-- 1 vagrant vagrant 713 Dec 2 12:36 proga.c -rw-r--r-- 1 root root 2048 Dec 2 12:44 proga.o -rwsr-xr-x 1 root root 8753 Dec 2 12:44 program drwxr-xr-x 2 root root 6 Dec 3 00:32 speckatalog
#пришло время воспользоваться нашей программой и создать пользователем vagrant подкаталог "proba_suid", #в каталоге "speckatalog" владельцем которого является суперпользователь root. Посмотрим что у нас получится теперь:
[00:33:03 vagrant@centos7:~/test] $ ./program Введите путь и имя создаваемого каталога: speckatalog/proba_suid сейчас будет создан каталог:speckatalog/proba_suid [00:51:07 vagrant@centos7:~/test] $ ls -lRa .: total 32 drwxrwxr-x 3 vagrant vagrant 107 Dec 3 00:32 . drwx------. 20 vagrant vagrant 4096 Dec 2 12:42 .. -rwxrwxr-x 1 vagrant vagrant 17 Nov 29 08:59 f1.txt -rwxrwxr-x 1 vagrant vagrant 0 Nov 29 05:37 f2.txt -rw-rw-r-- 1 vagrant vagrant 93 Dec 2 12:34 Makefile -rw-rw-r-- 1 vagrant vagrant 713 Dec 2 12:36 proga.c -rw-r--r-- 1 root root 2048 Dec 2 12:44 proga.o -rwsr-xr-x 1 root root 8753 Dec 2 12:44 program drwxr-xr-x 3 root root 18 Dec 3 00:51 speckatalog ./speckatalog: total 0 drwxr-xr-x 3 root root 18 Dec 3 00:51 . drwxrwxr-x 3 vagrant vagrant 107 Dec 3 00:32 .. drwxrwx--- 2 root vagrant 6 Dec 3 00:51 proba_suid ./speckatalog/proba_suid: total 0 drwxrwx--- 2 root root 6 Dec 3 00:51 . drwxr-xr-x 3 root root 18 Dec 3 00:51 ..
Как видно из двух примеров выше, создав от имени суперпользователя наш бинарник, функционал которого заключается в создании каталога по указанному нами пути, мы создали каталог, в каталоге root без использования sudo. Потому, что запуская такой бинарник от обычного пользователя vagrant, благодаря установленному флагу SUID, мы получили права его владельца root, но сохранив только принадлежность группы владельцев от пользователя vagrant. Если же мы установим и флаг SGID на наш бинарник, то мы наследуем и группу владельцев тоже от владельца root. Но об SGID флаге стоит тоже поговорить отдельно:
Теперь протестируем расширенные права SGID.
В случае же, если для нашего исполняемого файла, который умеет создавать каталоги, установлен бит sgid, то все каталоги, создаваемые им, наследуют группу root от нашего бинарника, при том, что запускаем мы его от обычного пользователя vagrant. Давайте установим новые расширенные флаги на наш бинарник и посмотрим какие каталоги он будет создавать.
☯
Terminal:
⌕
≡
✕
[04:30:51 vagrant@centos7:~/test] $ sudo chmod u-s program [04:31:34 vagrant@centos7:~/test] $ sudo chmod g+s program [04:31:41 vagrant@centos7:~/test] $ ls -la total 32 drwxrwxr-x 3 vagrant vagrant 107 Dec 3 02:57 . drwx------. 20 vagrant vagrant 4096 Dec 3 02:56 .. -rwxrwxr-x 1 vagrant vagrant 17 Nov 29 08:59 f1.txt -rwxrwxr-x 1 vagrant vagrant 0 Nov 29 05:37 f2.txt -rw-rw-r-- 1 vagrant vagrant 93 Dec 2 12:34 Makefile -rw-rw-r-- 1 vagrant vagrant 713 Dec 3 02:56 proga.c -rw-r--r-- 1 root root 2048 Dec 3 02:57 proga.o -rwxr-sr-x 1 root root 8753 Dec 3 02:57 program drwxr-xr-x 3 root root 23 Dec 3 04:29 speckatalog [04:31:46 vagrant@centos7:~/test] $
Сперва для урока, будет неудачная попытка по созданию подкаталога, в том же каталоге speckatalog. Но системный обработчик не увидит ошибку, потому что мы действуем своими, а не системными инструментами. Просто молча не выполнится создание каталога. Потому, что у speckatalog установлены права drwxr-xr-x, другими словами запись в него от имени группы тоже не предусмотрена, на месте нужной для этого w стоит(-), нам как членам группы, также как и всем остальным, кроме владельца, возможен только просмотр (r-x) содержимого, и исполнение(т.е. вход в каталог cd и показ содержимого ls).
[04:31:46 vagrant@centos7:~/test] $ ./program Введите путь и имя создаваемого каталога: speckatalog/proba_sgid сейчас будет создан каталог:speckatalog/proba_sgid [04:57:52 vagrant@centos7:~/test] $ ls -lRa total 32 drwxrwxr-x 3 vagrant vagrant 107 Dec 3 02:57 . drwx------. 20 vagrant vagrant 4096 Dec 3 02:56 .. -rwxrwxr-x 1 vagrant vagrant 17 Nov 29 08:59 f1.txt -rwxrwxr-x 1 vagrant vagrant 0 Nov 29 05:37 f2.txt -rw-rw-r-- 1 vagrant vagrant 93 Dec 2 12:34 Makefile -rw-rw-r-- 1 vagrant vagrant 713 Dec 3 02:56 proga.c -rw-r--r-- 1 root root 2048 Dec 3 02:57 proga.o -rwxr-sr-x 1 root root 8753 Dec 3 02:57 program drwxr-xr-x 3 root root 23 Dec 3 04:29 speckatalog ./speckatalog: total 0 drwxr-xr-x 3 root root 23 Dec 3 04:29 . drwxrwxr-x 3 vagrant vagrant 107 Dec 3 02:57 .. drwxrwx--- 2 root vagrant 6 Dec 3 04:29 proba_suid ./speckatalog/proba_suid: total 0 drwxrwx--- 2 root vagrant 6 Dec 3 04:29 . drwxr-xr-x 3 root root 23 Dec 3 04:29 ..
Так как в предыдущей попытке мы не получили нужный нам результат, то для осуществления задуманного добавим прав (w) на запись в каталог speckatalog, для группы тоже. И снова выполним задуманное.
[04:58:06 vagrant@centos7:~/test] $ sudo chmod g+w speckatalog [05:12:10 vagrant@centos7:~/test] $ ./program Введите путь и имя создаваемого каталога: speckatalog/proba_sgid сейчас будет создан каталог:speckatalog/proba_sgid [05:12:36 vagrant@centos7:~/test] $ ls -lRa total 32 drwxrwxr-x 3 vagrant vagrant 107 Dec 3 02:57 . drwx------. 20 vagrant vagrant 4096 Dec 3 02:56 .. -rwxrwxr-x 1 vagrant vagrant 17 Nov 29 08:59 f1.txt -rwxrwxr-x 1 vagrant vagrant 0 Nov 29 05:37 f2.txt -rw-rw-r-- 1 vagrant vagrant 93 Dec 2 12:34 Makefile -rw-rw-r-- 1 vagrant vagrant 713 Dec 3 02:56 proga.c -rw-r--r-- 1 root root 2048 Dec 3 02:57 proga.o -rwxr-sr-x 1 root root 8753 Dec 3 02:57 program drwxrwxr-x 4 root root 40 Dec 3 05:12 speckatalog ./speckatalog: total 0 drwxrwxr-x 4 root root 40 Dec 3 05:12 . drwxrwxr-x 3 vagrant vagrant 107 Dec 3 02:57 .. drwxrwx--- 2 vagrant root 6 Dec 3 05:12 proba_sgid drwxrwx--- 2 root vagrant 6 Dec 3 04:29 proba_suid ./speckatalog/proba_sgid: total 0 drwxrwx--- 2 vagrant root 6 Dec 3 05:12 . drwxrwxr-x 4 root root 40 Dec 3 05:12 .. ./speckatalog/proba_suid: total 0 drwxrwx--- 2 root vagrant 6 Dec 3 04:29 . drwxrwxr-x 4 root root 40 Dec 3 05:12 .. [05:12:40 vagrant@centos7:~/test] $
Теперь про удобную особенность бита SGID, если он установлен, не на бинарный файл, а на каталог
Мы рассмотрели как работает флаг SGID для исполняемого файла. В случае же, если этот бит SGID установлен на каталоге, то все объекты файловой системы, создаваемые внутри него, будут наследовать группу такого каталога. Эта возможность бывает очень кстати, когда например необходимо дать возможность разным пользователям создавать в определённом каталоге, свои личные объекты(файлы и каталоги), но с условием, чтобы все они принадлежали, одной - общей для всех, конкретной группе.
При этом стоит иметь ввиду, что флаг SUID для установки его на каталог не имеет смысла, но установленный SGID как раз наоборот поможет решить нам поставленную задачу.
Без этого бита, каждый пользователь имеющий права записи в каталог, по умолчанию создавал бы объекты от своего имени и от своей основной группы, но мы создадим свои правила и установим свой порядок, с помощью пары команд(если бы группа и пользователи у нас уже были...):
Что мы сделаем в примере:
- создать дополнительного пользователя vagrant2,
- Новую группу my_new.
- Включить в эту группу двух пользователей vagrant и vagrant2
- От суперпользователя(чтобы ограничить общий доступ) создадим каталог newcatalog. Изменить каталогу группу владельцев на my_new
- Создадим от имени первого, и второго, пользователей объекты, чтобы увидеть результат.
- Установить флаг SGID на каталог newcatalog
- И снова создать объекты, чтобы понять разницу, с предыдущими объектами...
Более подробно об операциях создания пользователей и групп смотрите в другой статье. Здесь нас больше интересует новое поведение каталога, с расширенными правами SGID.
Если же нужный каталог "newcatalog", с нужной под него группой "my_new", и подключённые к ней владельцы уже есть, то речь идёт о следующих двух действиях:
- установка на каталог новой группы владельцев
- и установка флага sgid:
sudo g+s newcatalog
Однако в примере, мы рассмотрим подробный вариант, в котором мы выполним все операции, создадим каталог, новую группу, добавим в неё пользователей, и протестируем SGID:
☯
Terminal:
⌕
≡
✕
смотрим под каким мы сейчас пользователем, есть ли у нас права администратора, в каких группах мы состоим [02:39:15 vagrant@centos7:~/test] $ whoami vagrant [02:39:31 vagrant@centos7:~/test] $ sudo whoami root [02:39:35 vagrant@centos7:~/test] $ id -Gn vagrant wheel
создаём новый каталог newcatalog от имени суперпользователя, видим, что у него права 755, а нам нужно 775 [02:39:41 vagrant@centos7:~/test] $ sudo mkdir newcatalog [02:39:50 vagrant@centos7:~/test] $ ls -la newcatalog total 0 drwxr-xr-x 2 root root 6 Dec 4 02:39 . drwxrwxr-x 4 vagrant vagrant 98 Dec 4 02:39 .. [02:39:56 vagrant@centos7:~/test] $
создаём в системе новую группу my_new, устанавливаем её на наш каталог, добавляем группе владельцев права записи w в каталог чтобы получить 770, убеждаемся что всё идёт по плану: [02:40:20 vagrant@centos7:~/test] $ sudo groupadd my_new [02:42:08 vagrant@centos7:~/test] $ sudo chgrp my_new newcatalog [02:42:21 vagrant@centos7:~/test] $ sudo chmod g+w newcatalog [02:42:30 vagrant@centos7:~/test] $ ls -la newcatalog total 0 drwxrwxr-x 2 root my_new 6 Dec 4 02:39 . drwxrwxr-x 4 vagrant vagrant 98 Dec 4 02:39 .. [02:42:35 vagrant@centos7:~/test] $
Пробуем создать подкаталог в нашем каталоге, но мы ещё не имеем прав, потому что не в группе владельцев; добавляем своего пользоватля в новую группу, и перелогиниваемся для активации принадлежность к новой группе. С новыми правами создаём подкаталог и файл в каталоге newcatalog. Смотрим результат: [02:43:06 vagrant@centos7:~/test] $ mkdir newcatalog/vd1 mkdir: cannot create directory ‘newcatalog/vd1’: Permission denied [02:43:26 vagrant@centos7:~/test] $ [02:43:36 vagrant@centos7:~/test] $ sudo usermod -aG my_new vagrant [02:43:41 vagrant@centos7:~/test] $ su vagrant Password: [02:43:53 vagrant@centos7:~/test] $ mkdir newcatalog/vd1 [02:44:30 vagrant@centos7:~/test] $ touch newcatalog/vf1 [02:44:48 vagrant@centos7:~/test] $ [02:48:11 vagrant@centos7:~/test] $ ls -la newcatalog total 0 drwxrwxr-x 3 root my_new 26 Dec 4 02:44 . drwxrwxr-x 4 vagrant vagrant 98 Dec 4 02:39 .. drwxrwxr-x 2 vagrant vagrant 6 Dec 4 02:44 vd1 -rw-rw-r-- 1 vagrant vagrant 0 Dec 4 02:44 vf1 [02:49:16 vagrant@centos7:~/test] $
Добавляем в систему нового пользователя vagrant2, для удобства сразу включая его в группу администратора wheel. И самое главное включаем его в новую группу my_new, чтобы дать права на запись в каталог newcatalog от своего имени. Создаём пользователю пароль. И логинимся под ним. Убеждаемся, что всё верно. [02:49:46 vagrant@centos7:~/test] $ sudo useradd -G wheel,my_new vagrant2 [02:50:00 vagrant@centos7:~/test] $ sudo passwd vagrant2 Changing password for user vagrant2. New password: BAD PASSWORD: The password is shorter than 8 characters Retype new password: passwd: all authentication tokens updated successfully. [02:50:11 vagrant@centos7:~/test] $ su vagrant2 Password: [02:50:24 vagrant2@centos7:/home/vagrant/test] $ whoami vagrant2 [02:50:33 vagrant2@centos7:/home/vagrant/test] $ sudo whoami [sudo] password for vagrant2: root [02:50:41 vagrant2@centos7:/home/vagrant/test] $ id -Gn vagrant2 wheel my_new
Создаём аналогично подкаталог и файл. Смотрим результат. Видим, что мы имеем каталоги и файлы от разных пользователей vagrant и vagrant2 и при этом объекты наследуют и основные группы владельцев, а не группу нашего каталога. И чем больше будет таких пользователей тем больше, будет таких совершенно разных объектов, принадлежащих разным группам..., но нам это не нужно. Не для этого мы создавали свою группу my_new [02:50:46 vagrant2@centos7:/home/vagrant/test] $ mkdir newcatalog/vd2 [02:51:15 vagrant2@centos7:/home/vagrant/test] $ touch newcatalog/vf2 [02:51:23 vagrant2@centos7:/home/vagrant/test] $ ls -la newcatalog total 0 drwxrwxr-x 4 root my_new 46 Dec 4 02:51 . drwxrwxr-x 4 vagrant vagrant 98 Dec 4 02:39 .. drwxrwxr-x 2 vagrant vagrant 6 Dec 4 02:44 vd1 drwxrwxr-x 2 vagrant2 vagrant2 6 Dec 4 02:51 vd2 -rw-rw-r-- 1 vagrant vagrant 0 Dec 4 02:44 vf1 -rw-rw-r-- 1 vagrant2 vagrant2 0 Dec 4 02:51 vf2
Исправляем ситуацию, путём добавления флага SGID для группы владельцев нашего каталога. И повторяем операции по созданию новых аналогичных объектов от обоих пользователей. [02:51:48 vagrant2@centos7:/home/vagrant/test] $ sudo chmod g+s newcatalog [02:52:22 vagrant2@centos7:/home/vagrant/test] $ mkdir newcatalog/vd2_2 [02:52:43 vagrant2@centos7:/home/vagrant/test] $ touch newcatalog/vf2_2 [02:52:49 vagrant2@centos7:/home/vagrant/test] $ su vagrant Password: [02:52:59 vagrant@centos7:~/test] $ mkdir newcatalog/vd1_1 [02:53:20 vagrant@centos7:~/test] $ touch newcatalog/vf1_1 [02:53:31 vagrant@centos7:~/test] $ [02:53:33 vagrant@centos7:~/test] $ ls -la newcatalog total 0 drwxrwsr-x 6 root my_new 94 Dec 4 02:53 . drwxrwxr-x 4 vagrant vagrant 98 Dec 4 02:39 .. drwxrwxr-x 2 vagrant vagrant 6 Dec 4 02:44 vd1 drwxrwsr-x 2 vagrant my_new 6 Dec 4 02:53 vd1_1 drwxrwxr-x 2 vagrant2 vagrant2 6 Dec 4 02:51 vd2 drwxrwsr-x 2 vagrant2 my_new 6 Dec 4 02:52 vd2_2 -rw-rw-r-- 1 vagrant vagrant 0 Dec 4 02:44 vf1 -rw-rw-r-- 1 vagrant my_new 0 Dec 4 02:53 vf1_1 -rw-rw-r-- 1 vagrant2 vagrant2 0 Dec 4 02:51 vf2 -rw-rw-r-- 1 vagrant2 my_new 0 Dec 4 02:52 vf2_2
Обратите внимание, что теперь все созданные подкаталоги наследуют не только имя группы родителя, но и флаг SGID. Поэтому все объекты создаваемые в этих подкаталогах будут рекурсивно наследовать такой же порядок. Создадим ещё пару подкаталогов, чтобы в этом убедиться [02:53:43 vagrant@centos7:~/test] $ mkdir newcatalog/vd1_1/vd1_1_1 [02:55:44 vagrant@centos7:~/test] $ ls -la newcatalog/vd1_1/vd1_1_1 total 0 drwxrwsr-x 2 vagrant my_new 6 Dec 4 02:55 . drwxrwsr-x 3 vagrant my_new 20 Dec 4 02:55 .. [02:55:51 vagrant@centos7:~/test] $ su vagrant2 Password: [02:56:28 vagrant2@centos7:/home/vagrant/test] $ mkdir newcatalog/vd2_2/vd2_2_2 [02:56:44 vagrant2@centos7:/home/vagrant/test] $ ls -la newcatalog/vd2_2/vd2_2_2 total 0 drwxrwsr-x 2 vagrant2 my_new 6 Dec 4 02:56 . drwxrwsr-x 3 vagrant2 my_new 20 Dec 4 02:56 .. [02:56:56 vagrant2@centos7:/home/vagrant/test] $
Теперь любые пользователи, из числа тех, кто включён в группу "my_new", смогут создавать файлы и каталоги внутри "~/test/newcatalog". Всем их созданным объектам, будет автоматически задана одна группа владельцев "my_new", а все каталоги и подкаталоги будут наследовать флаг SGID по умолчанию.
И понятно, что таким каталогом администратору системы, станет легко управлять. В зависимости от настроек umask(drwxrwsr-x) для каталога, все объекты файловой системы, могут быть, или не быть читаемыми, изменяемыми, или исполняемыми пользователями группы. Всем остальным соответственно тоже можно, легко и просто, выставлять свой уровень доступа к этому каталогу...
Пришло время обсудить для чего нужен третий бит расширенных прав t-бит или sticky bit
Каталоги расширенные права и защита от удаления
По умолчанию каталоги в Linux ведут себя не самым удобным во многих ситуациях образом. Обычно кто угодно может переименовать или удалить файл внутри каталога если у них есть права на запись в этом каталоге. Для каталогов, которыми владеют отдельные пользователи, такое поведение обычно не вызывает проблем, так как у них есть ограничение и по группе владельцев.
Однако для каталогов, которыми пользуется большое количество пользователей, под общей группой например, как с каталогом newcatalog из нашего предыдущего случая с флагом SGID, это может вызвать целую
кучу проблем. С таким уровнем доступа пользователи vagrant и vagrant2 могли бы поудалять файлы и объекты друг друга без всякого ограничения. Всё потому, что они принадлежат одной группе которая имеет полные права на каталог, и кто угодно такой же пользователь сможет удалять и переименовывать чьи угодно файлы — даже если они им не принадлежат! Очевидно, довольно сложно использовать такой каталог даже для временного хранения чего угодно, когда любой пользователь в любой момент может напечатать rm -rf ./newcatalog/* и уничтожить файлы всех остальных.
Хорошая новость в том, что в Linux существует ещё один инструмент расширенных прав так называемый sticky бит.
Когда для объекта (каталога или файла) установлен sticky бит (командой chmod +t), единственные, кто могут удалить или переименовать такие объекты файлы — это
либо владельцы этих файлов либо суперпользователь. Если же t-бит будет установлен на каталог, то и все создаваемые внутри него объекты, от пользователей будут наследовать это правило автоматически.
Воспользуемся созданной нами ситуацией в предыдущем примере:
- удалим из под пользователя vagrant2, чужой файл и подкаталог, который принадлежит общей группе my_new пользователя vagrant.
- Надеюсь уже понятно, что удалить мы сможем только объекты из одной группы, а первые файлы вне группы my_new мы не можем удалить, продемонстрируем и это тоже...
- А затем мы установим t-бит на свой подкаталог, чтобы защить объекты из одной группы, и создадим в нём ещё объекты, чтобы увидеть наследование.
- Зайдём в пользователя vagrant и попробуем "отомстить" и удалить эти защищённые файлы пользователя vagrant2...
☯
Terminal:
⌕
≡
✕
[11:18:19 vagrant2@centos7:/home/vagrant/test] $ ls -la ./newcatalog total 0 drwxrwsr-x 6 root my_new 94 Dec 4 02:53 . drwxrwxr-x 4 vagrant vagrant 98 Dec 4 02:39 .. drwxrwxr-x 2 vagrant vagrant 6 Dec 4 02:44 vd1 drwxrwsr-x 3 vagrant my_new 20 Dec 4 02:55 vd1_1 drwxrwxr-x 2 vagrant2 vagrant2 6 Dec 4 02:51 vd2 drwxrwsr-x 3 vagrant2 my_new 20 Dec 4 02:56 vd2_2 -rw-rw-r-- 1 vagrant vagrant 0 Dec 4 02:44 vf1 -rw-rw-r-- 1 vagrant my_new 0 Dec 4 02:53 vf1_1 -rw-rw-r-- 1 vagrant2 vagrant2 0 Dec 4 02:51 vf2 -rw-rw-r-- 1 vagrant2 my_new 0 Dec 4 02:52 vf2_2 [11:18:22 vagrant2@centos7:/home/vagrant/test] $ whoami vagrant2 [11:18:35 vagrant2@centos7:/home/vagrant/test] $ ls ./newcatalog/vd1_1 total 0 drwxrwsr-x 3 vagrant my_new 20 Dec 4 02:51 . drwxrwsr-x 6 root my_new 94 Dec 4 02:50 .. drwxrwsr-x 2 vagrant my_new 6 Dec 4 02:53 vd1_1_1 [11:19:28 vagrant2@centos7:/home/vagrant/test] $ rm -rf ./newcatalog/vd1_1/vd1_1_1 [11:19:58 vagrant2@centos7:/home/vagrant/test] $ ls ./newcatalog/vd1_1 [11:20:03 vagrant2@centos7:/home/vagrant/test] $ ls -la ./newcatalog/vd2_2 total 0 drwxrwsr-x 3 vagrant2 my_new 20 Dec 4 02:56 . drwxrwsr-x 6 root my_new 94 Dec 4 02:53 .. drwxrwsr-x 2 vagrant2 my_new 6 Dec 4 02:56 vd2_2_2 [11:26:28 vagrant2@centos7:/home/vagrant/test] $ chmod a+t ./newcatalog/vd2_2/ [11:26:37 vagrant2@centos7:/home/vagrant/test] $ ls -la ./newcatalog/vd2_2/vd2_2_2 total 0 drwxrwsr-x 2 vagrant2 my_new 6 Dec 4 11:26 . drwxrwsr-t 3 vagrant2 my_new 20 Dec 4 11:26 .. [11:26:44 vagrant2@centos7:/home/vagrant/test] $ ls -la ./newcatalog/vd2_2/ total 0 drwxrwsr-t 3 vagrant2 my_new 20 Dec 4 11:26 . drwxrwsr-x 6 root my_new 94 Dec 4 02:53 .. drwxrwsr-x 2 vagrant2 my_new 6 Dec 4 11:26 vd2_2_2 [11:29:45 vagrant2@centos7:/home/vagrant/test] $ su vagrant Password: [11:29:54 vagrant@centos7:~/test] $ rm -rf ./newcatalog/vd2_2/vd2_2_2 rm: cannot remove ‘./newcatalog/vd2_2/vd2_2_2’: Operation not permitted [11:30:09 vagrant@centos7:~/test] $ rm -rf ./newcatalog/vd2_2/ rm: cannot remove ‘./newcatalog/vd2_2/vd2_2_2’: Operation not permitted [11:30:33 vagrant@centos7:~/test] $ mkdir ./newcatalog/vd2_2/stop_it_i_have_a_sudo_just_in_case [11:32:04 vagrant@centos7:~/test] $ chmod a+t ./newcatalog/vd1_1/ [11:32:29 vagrant@centos7:~/test] $
Таким образом с помощью этого флага можно защитить каталоги от удаления. Таким же образом t-бит можно ставить и на одиночные файлы. Но удобно как мы рассмотрели в примере выше, его поставить на родительский каталог, сразу защитив тем самым, все дочерние объекты.
Список управления доступом Access Control List(ACL), утилиты (setfacl и getfacl)
Мы рассмотрели почти все возможные ситуации по установки основных и расширенных прав в Linux, но этот функционал не позволяет вам предоставлять разрешения более чем одному владельцу или одной группе владельцев на один объект. Такая возможность становится совершенно необходимой в условиях управления пользователями в корпоративных средах.
Для реализации максимально удобных структур прав доступа используются ACL (Access control list - cписки контроля доступа). Эти списки дают большую гибкость, чем стандартный набор полномочий «пользователь/группа/остальные».
Предполагается, что вы уже знакомы со стандартными правами систем Unix, приведённые вначале этой статьи, и с пониманием списков у вас не будет проблем. Потому что фактически это установка тех же самых прав rwx, только они добавляются поверх, к уже существующим правам для других пользователей и групп, не заменяя их, обеспечивая тем самым, совместно настроенный доступ к одним и тем же объектам.
Подумайте, обладая текущими знаниями как бы вы смогли предоставить новой группе пользователей, из предыдущего примера, с другим именем например my_new_acl такие же права, как и группе my_new на каталог newcatalog. Чтобы только у членов этих двух групп, был полный доступ к этому каталогу и ни у кого больше? Для решения подобных задач и существуют списки ACL.
При этом, списки контроля доступа позволяют устанавливать разрешения (ключ d: по умолчанию). (т.е. применяясь к объекту рекурсивно на всё дерево его подкаталогов после такой установки).
В основном вот, что нужно знать о списках ACL.
- Чтобы списки ACL работали, они должны быть включены в файловую систему при её монтировании.
- Например в Fedora, CentOS, Red Hat Enterprise Linux ... списки ACL автоматически включаются в любую файловую систему, созданную при установке системы.
- Если вы создаете файловую систему после установки (например, при добавлении дополнительного жёсткого диска), то должны убедиться, что параметр acl применяется при монтировании файловой системы (подробнее об этом позже).
- Чтобы добавить списки в файл, можно использовать команду setfacl, а чтобы просматривать списки ACL для файла — команду getfacl.
- Чтобы установить списки ACL для любого файла или каталога, вы должны быть его фактическим владельцем. Другими словами, назначение повышенных прав как у пользователя или члена группы с помощью setfacl не дает вам прав самостоятельно изменять списки ACL для этих файлов, если вы не их владелец, и не суперпользователь.
- Поскольку файлу/каталогу могут быть назначены несколько пользователей и групп, фактические права пользователя основаны на объединении всех назначений прав пользователям/группам, к которым он принадлежит. Например, если файл имеет разрешение только на чтение (r--) для группы sales и на чтение/запись (rw-) для группы marketing, и на исполнение (--x) для пользователя tony, а сам пользователь tony ещё и состоит в обоих группах, то у tony будет сумма всех прав, т.е. (rwx).
- Однако имейте ввиду, что права списков имееют более низкий приоритет, чем общие права доступа для пользователя и групп, которые ставятся утилитой chmod. Поэтому любые резрешения от списков ACL, не могут превышать общие правила. Как только вы устанавливаете списки ACL для файла, в файле задается маска максимально возможных привилегий, которые пользователь или группа ACL могут иметь для файла. Таким образом, даже если вы предоставляете пользователю больше прав через ACL, чем позволяют права группы, его права не будут превышать прав группы владельцев установленных через chmod.
- При этом запомните, что не все утилиты поддерживают ACL. Вы можете потерять настройки ACL при копировании или перемещении файлов, а программное обеспечение для резервного копирования может не выполнить резервное копирование настроек ACL. Например если архиватору tar не указать опции --acls, --selinux, --xattrs, то можно потерять настройки атрибутов и ACL. Но мы так делать не будем.
Весь необходимый фунционал ACL предусмотрен в утилитах getfacl, и setfacl. С помощью команды setfacl в списках ACL можно изменять права (-m) или удалить их (-x).
Синтаксис установки прав setfacl -m:
setfacl u: или g:имя пользователя или группы:rwx filenamesetfacl -m g:gruptony:rw ~/test
Здесь за параметром modify (-m) следует буква u , обозначающая, что вы устанавливаете права ACL для пользователя. После двоеточия (:) указываются имя пользователя, затем еще одно двоеточие и права, которые нужно назначить. Как и в случае с командой chmod, вы можете назначить пользователю или группе права на чтение (r), запись (w) и/или исполнение (x ) (в данном примере даются полные права rwx). Последний аргумент заменяется фактическим именем файла.
Синтаксис обнуления прав setfacl -x:
setfacl -x g:gruptony ~/test
Настройка списков ACL по умолчанию
Существуют два типа ACL:
- ACL для доступа;
- ACL по умолчанию.
ACL для доступа – это список управления доступом для заданного файла или каталога. Проще говоря – это сами права на объект,
которые будут контролировать доступ к этому объекту, это то с чего мы начали разговор.
ACL по умолчанию – может быть установлен только на каталог, и, если на конкретный файл в его подкаталогах нет никаких настроенных списков ACL, то такой файл
использует правила, определённые в ACL по умолчанию, установленные в одном из его родитительских каталогов. ACL по умолчанию являются необязательными.
Настройка списков ACL по умолчанию в каталоге позволяет работать с ними в будущем. Это означает, что при создании новых файлов и каталогов в этом каталоге им будут назначаться одни и те же списки ACL. Чтобы назначить пользователю или группе права в ACL по умолчанию, добавьте параметр d: перед ключами, к кому они относятся, u:(к пользователю), или g:(к группе), например:
Чтобы убедиться, что список ACL работает по умолчанию, создайте подкаталог в таком каталоге. Команда getfacl покажет действующие правила ACL. В родительском каталоге с настроенными списками (с опцией d: по умолчанию) создаются дочерние объекты с точно такими же списками. При просмотре объекта утилитой ls -la обратите внимание на знак плюс (+) справа, в выводе rw-rw-r--+. Он указывает на то, что какие-то ACL применялись на этом объекте, поэтому нужно запустить команду getfacl, чтобы увидеть, какие именно списки ACL там сейчас есть.
Просмотр настроенных списков команда getfacl:
getfacl /tmp/mary/subdir
Создание резервных копий или backup списков ACL:
Можно сохранять эти данные в файл, и делать таким образом свои резервные копии ACL. Чтобы получить резервную копию списков каталога /derectory в файл file.acl используйте ключ -R, чтобы сохранить список рекурсивно, вместе с данными списков и всех подкаталогов:
Чтобы восстановить настройки из этого файла резервной копии, путь и имена объектов указывать не нужно, они уже сохранены в файле. Просто используйте:
Обычно списки ACL применяются редко, даже реже чем флаги расширенных прав. Давайте посмотрим подробный пример, рассмотрим на практике как с ними работать:
- Добавим третьего пользователя vagrant3, но не включим его в общую группу my_new
- Cоздадим дополнительную группу которой тоже предоставим доступ для записи в каталог newcatalog с помощью списков ACL. В итоге к этому каталогу будут иметь доступ уже две разные группы, можно и больше по такому же принципу.
- Затем сделаем резервную копию списков в файл file.acl
- А потом применим операцию архивации каталога с помощью утилиты tar(с неправильными опциями, чтобы потерять ACL) и разархивации, таким образом настроенные списки изчезнут. Восстановим их из сохранённой копии из файла file.acl и повторим операцию архивирования, с правильными опциями tar чтобы убедиться, что эта утилита умеет сохранять списки ACL. Отдельно статью о других популярных архиваторах смотрите здесь.
- Убедимся, что приоритет общих прав доступа, выше прав созданных через списки ACL
Порядок всех этих действий смотрите в нашем весьма информативном терминале:
☯
Terminal:
⌕
≡
✕
_ / | | | | | |_| создадим дополнительную группу my_new_acl и дополнительного пользователя vagrant3 и сделаем его пока единственным участником этой группы.
[06:34:40 vagrant@centos7:~/test] $ sudo groupadd my_new_acl [06:36:15 vagrant@centos7:~/test] $ sudo useradd -G wheel,my_new_acl vagrant3 [06:36:54 vagrant@centos7:~/test] $ sudo passwd vagrant3 Changing password for user vagrant3. New password: BAD PASSWORD: The password is shorter than 8 characters Retype new password: passwd: all authentication tokens updated successfully. [06:37:10 vagrant@centos7:~/test] $ su vagrant3 Password: [06:37:29 vagrant3@centos7:/home/vagrant/test] $ whoami vagrant3 [06:37:49 vagrant3@centos7:/home/vagrant/test] $ id -Gn vagrant3 wheel my_new_acl [06:37:53 vagrant3@centos7:/home/vagrant/test] $ ls Makefile newcatalog proga.c proga.o program speckatalog
____ |___ \ __) | / __/ |_____| настроим дополнительные права с помощью списков ACL для нашего каталога newcatalog. А именно предоставим полный доступ к каталогу для новой группы my_new_acl, включив её в дополнительную группу, совместно с основной группой владельцев.
[06:38:53 vagrant3@centos7:/home/vagrant/test] $ sudo setfacl -m g:my_new_acl:rwx ./newcatalog [06:39:22 vagrant3@centos7:/home/vagrant/test] $ getfacl ./newcatalog # file: newcatalog # owner: root # group: my_new # flags: -s- user::rwx group::rwx group:my_new_acl:rwx mask::rwx other::r-x [06:39:47 vagrant3@centos7:/home/vagrant/test] $ ls -la ./newcatalog total 4 drwxrwsr-x+ 6 root my_new 94 Dec 5 05:01 . drwxrwxr-x 4 vagrant vagrant 98 Dec 4 02:39 .. drwxrwxr-x 2 vagrant vagrant 6 Dec 4 02:44 vd1 drwxrwsr-t 3 vagrant my_new 20 Dec 5 05:05 vd1_1 drwxrwxr-x 2 vagrant2 vagrant2 6 Dec 4 02:51 vd2 drwxrwsr-t 4 vagrant2 my_new 32 Dec 4 11:31 vd2_2 -rw-rw-r-- 1 vagrant vagrant 0 Dec 4 02:44 vf1 -rw-rw-r-- 1 vagrant my_new 0 Dec 4 02:53 vf1_1 -rw-rw-r-- 1 vagrant2 vagrant2 0 Dec 4 02:51 vf2 -rw-rw-r-- 1 vagrant2 my_new 0 Dec 4 02:52 vf2_2
Чтобы узнать возможности утилиты setfacl или getfacl просто как и обычно вызываем их с ключом --help, для больших подробностей, как и везде в linux можно использовать man setfacl
[06:16:37 vagrant@centos7:~/test] $ setfacl --help setfacl 2.2.51 -- set file access control lists Usage: setfacl [-bkndRLP] { -m|-M|-x|-X ... } file ... -m, --modify=acl modify the current ACL(s) of file(s) -M, --modify-file=file read ACL entries to modify from file -x, --remove=acl remove entries from the ACL(s) of file(s) -X, --remove-file=file read ACL entries to remove from file -b, --remove-all remove all extended ACL entries -k, --remove-default remove the default ACL --set=acl set the ACL of file(s), replacing the current ACL --set-file=file read ACL entries to set from file --mask do recalculate the effective rights mask -n, --no-mask don't recalculate the effective rights mask -d, --default operations apply to the default ACL -R, --recursive recurse into subdirectories -L, --logical logical walk, follow symbolic links -P, --physical physical walk, do not follow symbolic links --restore=file restore ACLs (inverse of `getfacl -R') --test test mode (ACLs are not modified) -v, --version print version and exit -h, --help this help text
создадим ещё один каталог vd3_3 от пользователя vagrant3, убедимся что флаги SGID, установленные в примере(предыдущий листинг) всё ещё работают несмотря на то, что мы не состоим в группе my_new, но просто имеем права на запись в этот каталог, благодаря настроенному списку ACL, с правами rwx для группы my_new_acl
[06:40:03 vagrant3@centos7:/home/vagrant/test] $ mkdir ./newcatalog/vd3_3 [06:40:59 vagrant3@centos7:/home/vagrant/test] $ ls -la ./newcatalog total 4 drwxrwsr-x+ 7 root my_new 106 Dec 5 06:40 . drwxrwxr-x 4 vagrant vagrant 98 Dec 4 02:39 .. drwxrwxr-x 2 vagrant vagrant 6 Dec 4 02:44 vd1 drwxrwsr-t 3 vagrant my_new 20 Dec 5 05:05 vd1_1 drwxrwxr-x 2 vagrant2 vagrant2 6 Dec 4 02:51 vd2 drwxrwsr-t 4 vagrant2 my_new 32 Dec 4 11:31 vd2_2 drwxrwsr-x 2 vagrant3 my_new 6 Dec 5 06:40 vd3_3 -rw-rw-r-- 1 vagrant vagrant 0 Dec 4 02:44 vf1 -rw-rw-r-- 1 vagrant my_new 0 Dec 4 02:53 vf1_1 -rw-rw-r-- 1 vagrant2 vagrant2 0 Dec 4 02:51 vf2 -rw-rw-r-- 1 vagrant2 my_new 0 Dec 4 02:52 vf2_2
_____ |___ / |_ \ ___) | |____/ Сделаем бэкап всех правил из списка ACL. Пока что у нас только одно правило ACL, на одном указанном каталоге... Но их может быть бесконечно много. Поэтому сохраним этот вывод в специальный файл, который станет нашим бэкапом списков ACL. Кстати полный бэкап всех существующих на данный момент списков ACL, можно сделать аналогичным образом, указав в качестве имени каталога корень /. Сначала мы просто делаем вывод на экран списка каталога newcatalog, с его подкаталогами. Чтобы понимать, что сохраним в файл на следующем шаге.
[06:17:11 vagrant@centos7:~/test] $ getfacl -R newcatalog # file: newcatalog # owner: root # group: my_new # flags: -s- user::rwx group::rwx group:my_new_acl:rwx mask::rwx other::r-x # file: newcatalog/vd1 # owner: vagrant # group: vagrant user::rwx group::rwx other::r-x # file: newcatalog/vf1 # owner: vagrant # group: vagrant user::rw- group::rw- other::r-- # file: newcatalog/vd2 # owner: vagrant2 # group: vagrant2 user::rwx group::rwx other::r-x # file: newcatalog/vf2 # owner: vagrant2 # group: vagrant2 user::rw- group::rw- other::r-- # file: newcatalog/vd2_2 # owner: vagrant2 # group: my_new # flags: -st user::rwx group::rwx other::r-x # file: newcatalog/vd2_2/vd2_2_2 # owner: vagrant2 # group: my_new # flags: -s- user::rwx group::rwx other::r-x # file: newcatalog/vd2_2/nu_nu # owner: vagrant # group: my_new # flags: -s- user::rwx group::rwx other::r-x # file: newcatalog/vf2_2 # owner: vagrant2 # group: my_new user::rw- group::rw- other::r-- # file: newcatalog/vf1_1 # owner: vagrant # group: my_new user::rw- group::rw- other::r-- # file: newcatalog/vd1_1 # owner: vagrant # group: my_new # flags: -st user::rwx group::rwx other::r-x # file: newcatalog/vd1_1/vd1_1_1 # owner: vagrant # group: my_new # flags: -s- user::rwx group::rwx other::r-x # file: newcatalog/vd3_3 # owner: vagrant3 # group: my_new # flags: -s- user::rwx group::rwx other::r-x [06:18:26 vagrant@centos7:~/test] $ getfacl -R newcatalog > file.acl
_ _ | || | | || |_ |__ _| |_| А сейчас мы увидим, как данные о списках ACL, "слетят" из-за того, что мы проделаем операцию архивирования утилитой tar, но без нужных опций. После разархивации из такого архива списки ACL обнуляются, потому что утилита tar, по умолчанию без опции --acls их не сохраняет. Затем мы восстановим данные списков из созданного нами бэкапа file.acl И снова сделаем процесс архивации, но с сохранением настроек ACL, теперь мы будет использовать утилиту tar с нужными опциями --acls, --selinux, --xattrs, чтобы при любых обстоятельствах сохранились в архив все атрибуты прав.
[10:58:05 vagrant@centos7:~/test] $ sudo tar -cvf newcatalog.tar ./newcatalog ./newcatalog/ ./newcatalog/vd1/ ./newcatalog/vf1 ./newcatalog/vd2/ ./newcatalog/vf2 ./newcatalog/vd2_2/ ./newcatalog/vd2_2/vd2_2_2/ ./newcatalog/vd2_2/nu_nu/ ./newcatalog/vf2_2 ./newcatalog/vf1_1 ./newcatalog/vd1_1/ ./newcatalog/vd1_1/vd1_1_1/ ./newcatalog/vd3_3/ [10:58:26 vagrant@centos7:~/test] $ ls -la total 48 drwxrwxr-x 4 vagrant vagrant 135 Dec 6 10:58 . drwx------. 20 vagrant vagrant 4096 Dec 3 06:31 .. -rw-rw-r-- 1 vagrant vagrant 1322 Dec 6 06:19 file.acls -rw-rw-r-- 1 vagrant vagrant 91 Dec 3 06:14 Makefile drwxrwsr-x+ 7 root my_new 106 Dec 5 06:40 newcatalog -rw-rw-r-- 1 root root 10240 Dec 6 10:58 newcatalog.tar -rw-rw-r-- 1 vagrant vagrant 1579 Dec 3 06:31 proga.c -rw-r--r-- 1 root root 2048 Dec 3 06:32 proga.o -rwsr-xr-x 1 root root 8753 Dec 3 06:32 program drwxrwxr-x 4 root root 40 Dec 3 06:33 speckatalog [10:59:07 vagrant@centos7:~/test] $ sudo rm -rf newcatalog [10:59:14 vagrant@centos7:~/test] $ ls file.acls Makefile newcatalog.tar proga.c proga.o program speckatalog [10:59:19 vagrant@centos7:~/test] $sudo tar -xvf newcatalog.tar ./newcatalog/ ./newcatalog/vd1/ ./newcatalog/vf1 ./newcatalog/vd2/ ./newcatalog/vf2 ./newcatalog/vd2_2/ ./newcatalog/vd2_2/vd2_2_2/ ./newcatalog/vd2_2/nu_nu/ ./newcatalog/vf2_2 ./newcatalog/vf1_1 ./newcatalog/vd1_1/ ./newcatalog/vd1_1/vd1_1_1/ ./newcatalog/vd3_3/ [10:59:34 vagrant@centos7:~/test] $ ls -la total 44 drwxrwxr-x 4 vagrant vagrant 135 Dec 6 10:59 . drwx------. 20 vagrant vagrant 4096 Dec 3 06:31 .. -rw-rw-r-- 1 vagrant vagrant 1322 Dec 6 06:19 file.acl -rw-rw-r-- 1 vagrant vagrant 91 Dec 3 06:14 Makefile drwxrwsr-x 7 root my_new 106 Dec 5 06:40 newcatalog -rw-rw-r-- 1 root root 10240 Dec 6 10:58 newcatalog.tar -rw-rw-r-- 1 vagrant vagrant 1579 Dec 3 06:31 proga.c -rw-r--r-- 1 root root 2048 Dec 3 06:32 proga.o -rwsr-xr-x 1 root root 8753 Dec 3 06:32 program drwxrwxr-x 4 root root 40 Dec 3 06:33 speckatalog [10:59:40 vagrant@centos7:~/test] $getfacl newcatalog # file: newcatalog # owner: root # group: my_new # flags: -s- user::rwx group::rwx other::r-x
Однако мы знали, что делаем... Поэтому всё-равно восстановим свои данные о списках из файла file.acl, который мы заблаговременно создали на предыдущих шагах. Восстановятся не только списки, но группы владельцев, и все флаги расширенных прав, если бы мы их тоже утеряли при неправильной архивации, например без прав sudo... Поэтому делать такие бэкапы прав, крайне полезно, даже если не использовать списки ACL.
[11:00:09 vagrant@centos7:~/test] $ sudo setfacl --restore=file.acl [11:00:39 vagrant@centos7:~/test] $ getfacl newcatalog # file: newcatalog # owner: root # group: my_new # flags: -s- user::rwx group::rwx group:my_new_acl:rwx mask::rwx other::r-x
Теперь воспользуемся той же утилитой tar, но с полностью правильными опциями
[02:03:10 vagrant@centos7:~/test] $ ls -la total 40 drwxrwxr-x 4 vagrant vagrant 4096 Dec 9 02:03 . drwx------. 21 vagrant vagrant 4096 Dec 9 01:47 .. -rw-rw-r-- 1 vagrant vagrant 1322 Dec 6 06:19 file.acls -rw-rw-r-- 1 vagrant vagrant 91 Dec 3 06:14 Makefile drwxrwsr-x+ 7 root my_new 4096 Dec 5 06:40 newcatalog -rw-rw-r-- 1 vagrant vagrant 1579 Dec 3 06:31 proga.c -rw-r--r-- 1 root root 2048 Dec 3 06:32 proga.o -rwsr-xr-x 1 root root 8753 Dec 3 06:32 program drwxrwxr-x 4 root root 40 Dec 3 06:33 speckatalog [02:03:18 vagrant@centos7:~/test] $ sudo tar --acls --selinux --xattrs -cvf s_t_newcatalog.tar ./newcatalog ./newcatalog/ ./newcatalog/vd1/ ./newcatalog/vf1 ./newcatalog/vd2/ ./newcatalog/vf2 ./newcatalog/vd2_2/ ./newcatalog/vd2_2/vd2_2_2/ ./newcatalog/vd2_2/nu_nu/ ./newcatalog/vf2_2 ./newcatalog/vf1_1 ./newcatalog/vd1_1/ ./newcatalog/vd1_1/vd1_1_1/ ./newcatalog/vd3_3/ [02:03:39 vagrant@centos7:~/test] $ sudo rm -rf newcatalog [02:03:54 vagrant@centos7:~/test] $ ls file.acls Makefile s_t_newcatalog.tar proga.c proga.o program speckatalog [02:03:58 vagrant@centos7:~/test] $ sudo tar --acls --selinux --xattrs -xvf s_t_newcatalog.tar ./newcatalog/ ./newcatalog/vd1/ ./newcatalog/vf1 ./newcatalog/vd2/ ./newcatalog/vf2 ./newcatalog/vd2_2/ ./newcatalog/vd2_2/vd2_2_2/ ./newcatalog/vd2_2/nu_nu/ ./newcatalog/vf2_2 ./newcatalog/vf1_1 ./newcatalog/vd1_1/ ./newcatalog/vd1_1/vd1_1_1/ ./newcatalog/vd3_3/ [02:04:16 vagrant@centos7:~/test] $ ls -la total 72 drwxrwxr-x+ 4 vagrant vagrant 4096 Dec 9 02:04 . drwx------. 21 vagrant vagrant 4096 Dec 9 01:47 .. -rw-rw-r-- 1 vagrant vagrant 1322 Dec 6 06:19 file.acls -rw-rw-r-- 1 vagrant vagrant 91 Dec 3 06:14 Makefile drwxrwsr-x+ 7 root my_new 4096 Dec 5 06:40 newcatalog -rw-r--r-- 1 root root 30720 Dec 9 02:03 s_t_newcatalog.tar -rw-rw-r-- 1 vagrant vagrant 1579 Dec 3 06:31 proga.c -rw-r--r-- 1 root root 2048 Dec 3 06:32 proga.o -rwsr-xr-x 1 root root 8753 Dec 3 06:32 program drwxrwxr-x 4 root root 40 Dec 3 06:33 speckatalog [02:04:19 vagrant@centos7:~/test] $ [02:04:19 vagrant@centos7:~/test] $ getfacl newcatalog # file: newcatalog # owner: root # group: my_new # flags: -s- user::rwx group::rwx group:my_new_acl:rwx mask::rwx other::r-x
____ | ___| |___ \ ___) | |____/ Мы упоминали в теоретической части, что права списков имееют более низкий приоритет, чем основные права доступа. Поэтому любые резрешения от списков ACL, не могут превышать общие правила, они могут только их урезать, но не расширить. Как только вы устанавливаете списки ACL для файла, в файле задается маска максимально возможных привилегий, которые пользователь или группа ACL могут иметь для файла. Таким образом, даже если вы предоставляете пользователю больше прав через ACL, чем позволяют права группы, его права не будут превышать прав группы владельцев установленных через chmod.
[09:15:51 vagrant3@centos7:/home/vagrant/test] $ sudo chmod g-w newcatalog [09:16:40 vagrant3@centos7:/home/vagrant/test] $ ls -la total 52 drwxrwxr-x+ 4 vagrant vagrant 4096 Dec 6 10:59 . drwx------. 20 vagrant vagrant 4096 Dec 3 06:31 .. -rw-rw-r-- 1 vagrant vagrant 1322 Dec 6 06:19 file.acls -rw-rw-r-- 1 vagrant vagrant 91 Dec 3 06:14 Makefile drwxr-sr-x+ 7 root my_new 106 Dec 5 06:40 newcatalog -rw-rw-r-- 1 vagrant vagrant 1579 Dec 3 06:31 proga.c -rw-r--r-- 1 root root 2048 Dec 3 06:32 proga.o -rwsr-xr-x 1 root root 8753 Dec 3 06:32 program drwxrwxr-x 4 root root 40 Dec 3 06:33 speckatalog [09:16:46 vagrant3@centos7:/home/vagrant/test] $ getfacl newcatalog # file: newcatalog # owner: root # group: my_new # flags: -s- user::rwx group::rwx #effective:r-x group:my_new_acl:rwx #effective:r-x mask::r-x other::r-x [09:16:54 vagrant3@centos7:/home/vagrant/test] $
Проверка системной поддержки списков ACL в вашей OS:
В современных системах Fedora и RHEL типы файловых систем xfs и ext (ext2, ext3, ext4), и btrfs создаются автоматически с поддержкой ACL. В других системах Linux или в файловых системах, созданных в них, для этого порой требуется добавить параметр монтирования acl несколькими способами. В современной Ubuntu поддержка ACL тоже включена и поддерживается ядром. Но, как бы то ни было, по умолчанию, в системе, ACL бывают не активированы.
Чтобы быть уверенным, что ACL будет работать в вашей системе, если у вас указанные выше файловые системы, то посмотрите чтобы не было параметра noacl в пятом поле у нужного вам раздела в файле /etc/fstab. Потому что по умолчанию, этот параметр у новых дистрибутивов обычно включен: (default: on) acl. Например у меня в системе не получилось отключить этот функционал списков, даже принудительно, записав в fstab параметр noacl. ACL работал в любом случае...
Инсталлятор Anaconda автоматически добавляет поддержку ACL в каждую файловую систему, которую формирует во время установки, а инструмент mkfs добавляет ACL в каждую файловую систему, которую вы создаете с его помощью.
Вот к примеру у следующей записи с файловой системой ext4, ACL включён потому, что не выключен...:
Однако в интернете, да и в книгах я встречал следующий совет, для идентификации списков ACL, который лично мне не пригодился:
"Чтобы убедиться, что параметр ACL был добавлен в файловую систему ext(X), определите имя устройства, связанное с ней, и выполните команду tune2fs -l для просмотра имплантированных параметров монтирования нужного вам раздела /dev/":
Этот способ работает если у вас файловая система ext2,3,4. Но он, не годится для машин с другими фс: btrfs, и с xfs, как мои текущие рабочие дистрибутивы fedora 34 и Centos 7, MX Linux 21, на примере которых сделан этот контент про списки ACL. Т.е. и с рабочими ACL, с такими ФС, при вызове tune2fs, вы получите ошибку(смотри в терминале ниже). Но разделы с ext4 успешно подтвердят, что acl включены:
☯
Terminal:
⌕
≡
✕
_____ _ _____ _ _ | ___|__ __| | ___ _ __ __ _ |___ /| || | | |_ / _ \/ _` |/ _ \| '__/ _` | |_ \| || |_ | _| __/ (_| | (_) | | | (_| | ___) |__ _| |_| \___|\__,_|\___/|_| \__,_| |____/ |_|
[user@fedora ~]$ sudo tune2fs -l /dev/nvme0n1p9 | grep "Default mount options:" tune2fs: Bad magic number in super-block while trying to open /dev/nvme0n1p9 ramanzes@fedora ~]$ sudo tune2fs -l /dev/nvme0n1p6 | grep "mount options" Default mount options: user_xattr acl
Тоже самое, я получаю и на виртуальной машине с CentOS у которой LVMы на xfs, и такой способ проверки данных файловых систем, как эти не подходит.
____ _ _____ / ___|___ _ __ | |_ ___ ___ |___ | | | / _ \ '_ \| __/ _ \/ __| / / | |__| __/ | | | || (_) \__ \ / / \____\___|_| |_|\__\___/|___/ /_/
[01:41:12 root@centos7:/home/vagrant/test] # lsblk -f NAME FSTYPE LABEL UUID MOUNTPOINT sda ├─sda1 xfs 44e5d762-7957-4c35-afca-de806b2d5f40 /boot └─sda2 LVM2_member ljQvhs-xzfL-ba6a-316w-YpfH-BSVk-nKnKZA ├─centos-swap swap b794b19d-4b5f-400a-8507-dca1c409da86 [SWAP] └─centos-root xfs 8c99abdd-12c1-4e2b-beef-f3c20b841aab / [01:57:32 vagrant@centos7:~/test] $ sudo tune2fs -l /dev/mapper/centos-root | grep "mount options" tune2fs: Bad magic number in super-block while trying to open /dev/mapper/centos-root Couldn't find valid filesystem superblock. [03:24:22 vagrant@centos7:~] $ sudo setfacl -m u:vagrant:rwx /tmp [03:25:31 vagrant@centos7:~] $ sudo getfacl /tmp getfacl: Removing leading '/' from absolute path names # file: tmp # owner: root # group: root # flags: --t user::rwx user:vagrant:rwx group::rwx mask::rwx other::rwx
__ ____ __ _ _ ____ _ | \/ \ \/ / | | (_)_ __ _ ___ __ |___ \/ | | |\/| |\ / | | | | '_ \| | | \ \/ / __) | | | | | |/ \ | |___| | | | | |_| |> < / __/| | |_| |_/_/\_\ |_____|_|_| |_|\__,_/_/\_\ |_____|_|
root@mx1:/root # tune2fs -l /dev/sda2 | grep "mount options" Default mount options: user_xattr acl
Хотя мне и не пришлось убедиться в существовании подобной проблемы, но перед началом работы с ACL может потребоваться подготовить файловую систему для поддержки ACL. Поскольку метаданные файловой системы необходимо расширять, не всегда есть поддержка по умолчанию для ACL в файловой системе. Если при настройке списков ACL для файловой системы вы получаете сообщение «operation not supported», возможно, в вашей файловой системе отсутствует поддержка ACL. Если ваша файловая система не была смонтирована с опцией «acl», вы можете перемонтировать ее, предоставив необходимую опцию:
Однако обратите внимание, что параметры монтирования, заданные таким образом, не будут постоянными и не сохранятся после перезагрузки. Если вы хотите получить постоянство в этой настройке, вам нужно изменить параметры монтирования файловой системы в /etc/fstab, назначив опцию «acl» статически.
Чтобы это исправить, вам нужно добавить опцию в файле /etc/fstab, поддержку ACL при монтировании. Добавьте на строке вашего раздела после типа файловой системы, слово acl, например:
Дополнительный модуль повышения безопасности, развёрнутый над Linux
SELinux обеспечивает повышенную безопасность в системе Linux с помощью управления доступом на основе ролей (RBACs) к субъектам и объектам (они же процессы и ресурсы).
SELinux - это система МАРКИРОВКИ, каждого процесса. У каждого файла, каталога и системного объекта есть МЕТКА. Правила политики управляют доступом между помеченными процессами и помеченными объектами. Ядро обеспечивает соблюдение этих правил.
Role-based access control(RBAC) чем отличается от ACL, для понимания в общих чертах. Например, ACL можно использовать для предоставления или запрета доступа на запись к определенному системному файлу, но он не будет указывать, как именно этот файл может быть изменён. В системе на основе RBAC операция может заключаться в конкретной транзакции: «создать кредитный счет» в финансовом приложении, или «заполнить запись теста на уровень сахара в крови» в медицинском приложении. Таким образом, роль - это последовательность операций в рамках более крупной деятельности. Было показано, что RBAC особенно хорошо подходит для требований разделения обязанностей (SoD), которые гарантируют, что два или более человека должны участвовать в авторизации критических операций. Проанализированы необходимые и достаточные условия безопасности SoD в RBAC. Основополагающий принцип SoD заключается в том, что ни один человек не должен иметь возможность нарушить безопасность с помощью двойных привилегий.
Где мы можем это сразу увидеть:
☯
Terminal:
⌕
≡
✕
[07:03:54 vagrant@centos7:/home] $ ls -l total 4 drwx------. 21 vagrant vagrant 4096 Dec 10 07:02 vagrant drwx------ 5 vagrant2 vagrant2 121 Dec 6 11:10 vagrant2 drwx------ 5 vagrant3 vagrant3 121 Dec 6 11:10 vagrant3
SELinux обеспечивает комбинацию управления доступом на основе ролей (RBAC), многоуровневой безопасности (multi-level security, MLS) и модели принудительной типизации доступа (type enforcement, TE).
[07:18:05 vagrant@centos7:/home] $ ls -lZ drwx------. vagrant vagrant unconfined_u :object_r :user_home_dir_t :s0 vagrant drwx------ vagrant2 vagrant2 ? vagrant2 drwx------ vagrant3 vagrant3 ? vagrant3
С командой ls -Z отображаются четыре связанных с файлом элемента, которые относятся к SELinux. В списке контекста безопасности файла находится следующее. user Файл сопоставляется с пользователем SELinux unconfined_u. role Файл сопоставляется с ролью :object_r. type Файл считается частью домена :user_home_dir_t. level: sensitivity. У этого пользователя есть только один уровень чувствительности, и он самый низкий — :s0; categories. Модель MCS для этого файла не установлена.
[09:49:09 vagrant@centos7:/home] $cat /etc/selinux/config # This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - No SELinux policy is loaded. SELINUX=disabled # SELINUXTYPE= can take one of these two values: # targeted - Targeted processes are protected, # minimum - Modification of targeted policy. Only selected processes are protected. # mls - Multi Level Security protection. SELINUXTYPE=targeted
[user@fedora ~]$ sudo getenforce Disabled [user@fedora ~]$ sestatus SELinux status: disabled
Эти четыре элемента (Role-based access control)RBAC (пользователь, роль, тип и уровень) применяются в управлении доступом SELinux для определения соответствующих уровней доступа. Вместе эти элементы называются контекстом безопасности SELinux. Контекст безопасности (значок ID) иногда называют меткой безопасности.
Элементы контекста безопасности присваиваются субъектам (процессам и пользователям). Каждый контекст безопасности имеет имя. Оно зависит от того, какому объекту или субъекту присвоено. То есть файлы имеют контекст файла, пользователи имеют контекст пользователя, а процессы имеют контекст процесса, также называемый доменом.
Правила, разрешающие доступ, называются разрешающими правилами или правилами политики. Правило политики — это процесс, которого SELinux придерживается, чтобы предоставить или запретить доступ к определенному типу безопасности системы. Возвращаясь к сравнению, SELinux служит охранником, который должен увидеть контекст безопасности субъекта (значок ID) и просмотреть правила политики (руководство по правилам доступа), прежде чем разрешить или запретить доступ к объекту. Таким образом, принудительная типизация доступа гарантирует, что только определенные типы субъектов могут получить доступ к определенным типам объектов.
Если учитывать, что данный модуль используется ещё реже даже чем списки ACL и в подавляющем количестве случаев просто не активен,
то в рамках этого раздела, вполне достаточно, чтобы понять, что символ (.) при выводе атрибутов файла указывает о наличии правил SELinux, которые имеют огромное значения, но только когда SELinux включён и активен...
Однако тема целевой настройки модуля SElinux огромна, и требует отдельного рассмотрения в другом разделе сайта - здесь.