Наследование прав на файлы и папки в Linux
На самом деле, речь в этой статье пойдёт не только о наследовании прав на файлы и каталоги в операционных системах семейства Linux. Однако наследование прав доступа будет первой и основной темой, которая будет здесь затронута.
Многие пользователи Windows в курсе, как работает система наследования прав. Суть её в том, что пользователи и группы будут иметь те же права на файлы и каталоги, которые они имели по отношению к родительскому каталогу. В Linux механизм наследования работает схожим образом и называется «правами по умолчанию». Несмотря на своё название, права по умолчанию вовсе не задаются автоматически. Их нужно прописать отдельно. Для примера используем каталог пользователя test:
Этой командой мы дали пользователю tux те же права по умолчанию, что и у владельца каталога.
Для удаления прав по умолчанию используется команда
Кроме наследования прав есть и другие особенности ACL, которые будет полезно рассмотреть. Первым делом рассмотрим сохранение (или нет) ACL-прав при операциях над файлами и папками:
Как видим, логика операций здесь довольно проста.
Другой интересной возможностью в работе с ACL-правами доступа будут так называемые автоматические операции.
Первой из таких операций является перенос ACL-прав. Это значит, что мы снимаем ACL-права с одного объекта и придаём их другому. Ранее мы рассматривали файл file_test в каталоге /home/test/. Перенесём ACL-доступы с него на файл file_test2 командой
На скриншоте выше можно наблюдать права на файл file_test2 до и после применения команды по переносу ACL-прав.
Если же нужно не перенести, а скопировать ACL-права с одного объекта на другой, то здесь поможет другая команда:
Эта команда не заменит права, как предыдущая, а добавит их к уже существующим.
Еще одним неплохим приемом может стать копирование ACL-прав на каталог в права по умолчанию этого же каталога. По сути, это то же самое, что мы провернули в начале статьи. Вот только тогда мы могли задать любые другие права по умолчанию. А вот если нам надо именно скопировать текущие права, то будет проще воспользоваться следующей командой:
Здесь dir1 и dir2 являются каталогами, между которыми мы копируем права по умолчанию.
ИТ База знаний
Полезно
— Онлайн генератор устойчивых паролей
— Онлайн калькулятор подсетей
— Руководство администратора FreePBX на русском языке
— Руководство администратора Cisco UCM/CME на русском языке
— Руководство администратора по Linux/Unix
Навигация
Серверные решения
Телефония
FreePBX и Asterisk
Настройка программных телефонов
Корпоративные сети
Протоколы и стандарты
Владельцы файлов и папок в Linux
Основные команды для работы с правами доступа:
В Windows у нас есть только один владелец файла или папки. Это можно посмотреть в свойствах объекта на вкладке безопасность, дополнительно и там же мы можем сменить владельца. Владелец в Windows по умолчанию обладает полными правами на объект. В Linux все происходит немного по-другому: Любой объект моет иметь своего владельца и группу владельцев, и кроме этого для объекта существуют все остальные пользователи в системе. Это самое существенное различие, что может быть владелец и группа владельцев.
Пример: sudo chown –R siadmin:testusers Folder
Права доступа
Для того, чтобы далее разбираться с темой прав, надо запомнить вот такую табличку.
Еще один не маловажный момент мы назначаем права на файл, сразу для всех видов пользователей. Следовательно, указывая права, мы их сразу задаем для владельца, для группы владельца и всех остальных. Права мы можем назначать. Точно так же как на картинке символами rwx или цифрами, согласно табличке. Для лучшего понимания пример:
Когда мы просматриваем права на объекты мы видим символьные обозначения, а там, где нет символа ставится прочерк, который означает, что данное право отсутствует.
Чтобы легче было определять права на объект надо мысленно разделить на блоки по 3 символа. Первый блок — это Владелец, 2-й Блок — это группа владельца и 3-й блок — это другие пользователи.
Разберемся с правом на execute – выполнение.
Понятно становится это права, когда мы имеет дело с каким-то скриптом или бинарником или программой исполняемой. Так же у нас данное право может назначаться на каталог, а каталог мы исполнить не можем. Но тут есть интересный момент, если у вас будет на папку разрешение только на чтение и запись, прочитать папку, переименовать ее т.е поработать с наименованием папки, но в глубь папки вы не сможете зайти. Чтобы зайти во внутрь папки необходимо право execute – т.е выполнение ее.
Маска создания файлов и папок
В данной части статьи рассмотрим следующий вопрос:
Понимание принципов работы и управления масками создания файлов и папок.
suid – set user id, который позволяет, если установлен на исполняемый файл, то любой пользователь, который запускает, получает права определенные для владельца данного файла. По-другому, позволяет использовать права владельца данного файла, происходит некая подмена вас на владельца этого файла.
sgid – set user id, который позволяет, если установлен на исполняемый файл, то любой пользователь, который запускает, получает права определенные для группы владельца данного файла. По-другому, позволяет использовать права группы владельца данного файла, происходит некая подмена вас на пользователя входящего в группу владельца этого файла.
Маска это такая интересная штука, которая указывает права по–умолчанию. Она рассчитывается с помощью вычитания из максимальных прав. Примеры вычисления показаны на картинке.
Посмотрим, как выглядит это в консоли.
Нужно обратить внимание, что при создании папки права на выполнение по умолчанию выдаются, а на файл нет. Это связанно с тем, что без данных прав в данную папку невозможно будет зайти, а с файла убираются в целях защиты. Например, если вдруг окажется, что файл – это вредоносный код.
Suid, sgid, sticky
Так же эти биты можно ставить, через буквы:
Как мы видим suid добавляется к правам владельца, sguid прибавляется к правам группы владельца. Sticky добавляется к правам всем остальным.
Результат наших действий подсвечен желтым.
Можно одновременно оба бита установить, следовательно, при выполнении будет и владелец заменен и группа заменена. Это имеет смысл делать, только для исполняемых файлов. Устанавливать на обычный текстовый файл данные биты, смысла конечно же нет.
Очень редко, когда применяю оба бита сразу, такое сочетание необходимо если уж сильно кто-то заморачивается с безопасностью или требуется ювелирная настройка прав доступа и запуска.
Теперь посмотрим, что с папкой происходит. На папку можно устанавливать sgid и sticky биты. Если мы устанавливаем групповой бит, то он для папок будет менять владельцев всех вложенных файлов на группу владельцев этой папки, т.е это один из вариантов наследования.
Создадим в ней такой же файл sudo touch TestFolder/file.txt
Теперь про sticky бит. Если установлен sticky бит на папку, то только Владелец данной папки или суперпользователь может удалить из нее файлы.
Онлайн курс по Linux
Мы собрали концентрат самых востребованных знаний, которые позволят тебе начать карьеру администратора Linux, расширить текущие знания и сделать уверенный шаг к DevOps
Права доступа Unix, SUID, SGID, Sticky биты
Содержание
Вступление
В Unix каждому файлу соответствует набор прав доступа, представленный в виде 9-ти битов режима. Он определяет, какие пользователи имеют право читать файл, записывать в него данные или выполнять его. Вместе с другими тремя битами, влияющими на запуск исполняемых файлов, этот набор образует код режима доступа к файлу. Двенадцать битов режима хранятся в 16-битовом поле индексного дескриптора вместе с 4-мя дополнительными битами, определяющими тип файла. Последние 4 бита устанавливаются при создании файлов и не подлежат изменению. Биты режима (далее права) могут изменяться либо владельцем файла, либо суперпользователем с помощью команды chmod.
Существует три пути управления доступом к файлу или каталогу. Было определено, что каждый файл должен иметь владельца (owner), группового владельца (group owner), а также может потребоваться доступ для всех остальных пользователей (everyone). Эти названия обычно приводятся как пользователь/группа/остальные (user/group/others) или коротко ugo. Реализация управления доступом к файлам и каталогам в Unix позволяет или запрещает доступ по трем флагам: флаг чтения (Read), флаг записи (Write), флаг выполнения (eXecute). Они представляются следующим образом:
Флаг типа (flag) может быть одним из следующих:
Права доступа
Посмотреть права доступа на объекты можно командой ls c ключем -l («л»). Также можно добавить ключ -a, для того,чтобы были отображены скрытые объекты:
Рассмотрим таблицу, чтобы было понятнее:
Для администрирования часто удобнее использовать не буквенное представление прав, а цифровое, в восьмеричном представлении (оно короче). Так, например, права на файл всем и вся, соответствуют записи 777 (что аналогично символьному представлению rwxrwxrwx).
Существуют также специальные биты, такие как SUID, SGID и Sticky-бит. SUID, SGID влияют на запуск файла, а Sticky влияет на определение владельца объектов в каталоге. При их применении необходимо использовать не три восьмеричных цифры, а 4. Зачастую, в различной технической литературе права обозначаются именно 4-мя цифрами, например 0744. Многие стараются не использовать специальные биты, сетуя на безопасность (и не без основательно), но, в некоторых ситуациях без них не обойтись. Поговорим о них несколько позже.
Давайте рассмотрим пример, итак:
Восьмеричное обозначение прав для файла pro_ubuntu.zip: 0700.
Для второй строки (это каталог, о чем свидетельствует флаг «d»), по аналогии:
Восьмеричное обозначение в этом примере: 0755.
На практике для каталогов используется только три режима: 7 (rwx), 5 (r-x) и 0 (—).
Но не надо думать, что такой каталог полноценно заменяет крипто-контейнер (т.е. может использоваться для хранения очень секретных данных). Да, имен объектов из такого каталога никак не получить, однако если попытаться создать объект с именем, которое уже существует, то такая операция закончится неудачей (т.е. мы получим подтверждение, что такое имя уже есть). Так же можно пытаться открыть (как файл или как каталог) объект с произвольным именем, если такого имени нет, то мы получим ошибку. Безусловно имя может быть очень длинным и шансы угадать его могут быть не велики, но не надо забывать, что права доступа могут сменить как владелец каталога так root. Да и пути доступа могут сохраниться в различных логах и файлах истории.
Команда chmod
Права устанавливаются командой chmod. Команда chmod поддерживает установку прав как в восьмеричном представлении, так и в символьном (маска режима доступа).
Синтаксис команды прост:
chmod
Опции
Из самых полезных и часто используемых опций можно выделить одну:
Права
Права можно записывать как в восьмеричном представлении так и в символьном. В восьмеричном представлении, для стандартных прав, указываются 3 восьмеричные цифры (1-я для владельца, 2-я для группы, 3-я для всех остальных. См. таблицу выше).
Для назначения прав используются три знака: минус, плюс или равно:
Использование символьного представления позволяет редактировать права файлов более гибко:
Символьное назначение окажет неоценимую услугу, если требуется добавить права на объект к уже существующим правам.
Массовое назначение прав
Иногда, бывает, нужно массово установить права на определенный тип объектов, например, только на каталоги или только на файлы. Простое использование опции -R (рекурсия) здесь не поможет т.к. chmod будет проходить по всем объектам удовлетворяющим маске, что иногда вовсе не то, что нужно.
Итак, чтобы массово установить права на определенный тип объектов можно использовать один из вариантов (вообще, их очень много):
Более длинный вариант аналогичной операции:
Биты SUID, SGID и Sticky
Если при создании пользователя основная группа не указана явно, то основной группой пользователя будет группа с тем же именем, что и имя пользователя. Например:
Что касается процессов, то с ними связано не два идентификатора, а 4-е: реальный и эффективный пользовательский (UID), а также реальный и эффективный групповой (GID). Реальные номера применяются для учета использования системных ресурсов, а эффективные для определения прав доступа к процессам. Как правило, реальные и эффективные идентификаторы совпадают. Владелец процесса может посылать ему сигналы, а также изменять приоритет.
Вобщем, одним словом установка битов SUID или SGID позволит пользователям запускать исполняемые файлы от имени владельца (или группы) запускаемого файла. Например, как говорилось выше, команду chmod по умолчанию может запускать только root. Если мы установим SUID на исполняемый файл /bin/chmod, то обычный пользователь сможет использовать эту команду без использования sudo, так, что она будет выполнятся от имени пользователя root. В некоторых случаях очень удобное решение. Кстати по такому принципу работает команда passwd, c помощью которой пользователь может изменить свой пароль.
Однако, в системе FreeBSD, если скомпилировать ядро с поддержкой suiddir, а так же смонтировать раздел с этой опцией, то, все объекты создаваемые в каталоге где установлен SUID будут иметь владельца этого каталога (наследование). Реализация подобного в Linux возможна (?) на файловой системе GFS2. Данная функция считается уязвимостью.
Установить SUID и SGID можно командой chmod:
Права в Linux (chown, chmod, SUID, GUID, sticky bit, ACL, umask)
Чтобы получить доступ к файлам в Linux, используются разрешения. Эти разрешения назначаются трем объектам: владельцу файла, владельцу группы и другому объекту (то есть всем остальным). В этой статье вы узнаете, как применять разрешения.
Статья начинается с обзора основных понятий, после чего обсуждаются специальные разрешения (Special permissions) и списки контроля доступа (ACL). В конце этой статьи рассматривается настройка прав доступа по умолчанию через umask, а также управление расширенными атрибутами пользователя.
Управление владением файлами
Прежде чем обсуждать разрешения, вы должны знать о роли владельца файла и каталога. Владение файлами и каталогами жизненно важно для работы с разрешениями. В этом разделе вы сначала узнаете, как вы можете увидеть владельца. Затем вы узнаете, как изменить владельца группы и пользователя для файлов и каталогов.
Отображение владельца файла или каталога
В Linux у каждого файла и каждого каталога есть два владельца: пользователь и владелец группы.
Эти владельцы устанавливаются при создании файла или каталога. При создании пользователь, который создает файл, становится владельцем пользователя, а основная группа этого пользователя становится владельцем группы. Чтобы определить, есть ли у вас как у пользователя права доступа к файлу или каталогу, оболочка проверяет владение.
Это происходит в следующем порядке:
Вы также можете использовать find для поиска файлов, у которых определенная группа является их владельцем.
Например, следующая команда ищет все файлы, принадлежащие группе users:
Изменение владельца
Чтобы применить соответствующие разрешения, первое, что нужно учитывать, это владение. Для этого есть команда chown. Синтаксис этой команды не сложен для понимания:
Например, следующая команда меняет владельца каталога /home/account на пользователя linda:
Команда chown имеет несколько опций, одна из которых особенно полезна: -R. Вы можете догадаться, что он делает, потому что эта опция доступна и для многих других команд. Это позволяет вам рекурсивно устанавливать владельца, что позволяет вам установить владельца текущего каталога и всего, что находится ниже. Следующая команда меняет владельца для каталога /home и всего, что находится под ним, на пользователя linda:
Сейчас владельцы выглядят так:
Теперь пользователь lisa стал владельцем каталога account:
Изменение владельца группы
Есть два способа изменить владение группой. Вы можете сделать это, используя chown, но есть специальная команда с именем chgrp, которая выполняет эту работу. Если вы хотите использовать команду chown, используйте . или : перед названием группы.
Следующая команда изменяет какого-либо владельца группы /home/account на группу account:
Вы можете использовать chown для изменения владельца пользователя и/или группы несколькими способами. Вот несколько примеров:
chown lisa myfile1 устанавливает пользователя lisa владельцем файла myfile1.
chown lisa.sales myfile устанавливает пользователя lisa владельцем файла myfile, а так же устанавливает группу sales владельцем этого же файла.
chown lisa:sales myfile тоже самое, что и предыдущая команда.
chown :sales myfile тоже самое, что и предыдущая команда.
Вы можете использовать команду chgrp, чтобы изменить владельца группы. Рассмотрим следующий пример, где вы можете с помощью chgrp установить владельцем каталога account группу sales:
Как и в случае с chown, вы можете использовать опцию -R с chgrp, а также рекурсивно менять владельца группы.
Понимание владельца по умолчанию
Вы могли заметить, что когда пользователь создает файл, применяется владение по умолчанию.
Пользователь, который создает файл, автоматически становится владельцем этого файла, а основная группа этого пользователя автоматически становится владельцем этого файла. Обычно это группа, которая указана в файле /etc/passwd в качестве основной группы пользователя. Однако, если пользователь является членом нескольких групп, он может изменить эффективную основную группу.
Чтобы показать текущую эффективную первичную группу, пользователь может использовать команду groups:
Если текущий пользователь linda хочет изменить эффективную первичную группу, он будет использовать команду newgrp, за которой следует имя группы, которую он хочет установить в качестве новой эффективной первичной группы. После использования команды newgrp, первичная группа будет активна, пока пользователь не введет команду exit или не выйдет из системы.
Ниже показано, как пользователь linda использует эту команду, что первичной группой стала группа sales:
Чтобы вернуться к исходной настройке первичной группы, используйте exit.
Чтобы иметь возможность использовать команду newgrp, пользователь должен быть членом той группы, которую он хочет использовать в качестве первичной.
Кроме этого, групповой пароль может быть использован для группы с помощью команды gpasswd. Если пользователь использует команду newgrp, но не является членом целевой группы, оболочка запрашивает пароль группы. После того, как вы введете правильный групповой пароль, будет установлена новая эффективная первичная группа.
Управление основными правами
Система разрешений Linux была изобретена в 1970-х годах. Поскольку вычислительные потребности были ограничены в те годы, базовая система разрешений была довольно ограничена. Эта система разрешений использует три разрешения, которые можно применять к файлам и каталогам. В этом разделе вы узнаете, как использовать и изменять эти разрешения.
Понимание прав на чтение, запись и выполнение
Три основных разрешения позволяют вам читать, записывать и выполнять файлы. Эффект этих разрешений отличается при применении к файлам или каталогам. Применительно к файлу разрешение на чтение дает вам право открыть файл для чтения. Следовательно, вы можете прочитать его содержимое, но это означает, что ваш компьютер может открыть файл, чтобы что-то с ним сделать. Программный файл, которому требуется доступ к библиотеке, должен, например, иметь доступ для чтения к этой библиотеке. Из этого следует, что разрешение на чтение — это самое основное разрешение, которое вам нужно для работы с файлами.
Применительно к каталогу чтение позволяет отображать содержимое этого каталога. Вы должны знать, что это разрешение не позволяет вам читать файлы в каталоге. Система разрешений Linux не знает наследования, и единственный способ прочитать файл — использовать разрешения на чтение для этого файла.
Как вы, вероятно, можете догадаться, разрешение на запись, если оно применяется к файлу, позволяет записывать в файл. Иначе говоря, позволяет изменять содержимое существующих файлов. Однако он не позволяет создавать или удалять новые файлы или изменять права доступа к файлу. Для этого вам нужно дать разрешение на запись каталогу, где вы хотите создать файл. В каталогах это разрешение также позволяет создавать и удалять новые подкаталоги.
Разрешение на выполнение — это то, что вам нужно для выполнения файла. Он никогда не будет установлен по умолчанию, что делает Linux практически полностью невосприимчивым к вирусам. Только кто-то с административными правами на каталог может применять разрешение на выполнение.
Ниже обобщается использование основных разрешений:
Использование chmod
Для управления правами используется команда chmod. При использовании chmod вы можете устанавливать разрешения для пользователя (user), группы (group) и других (other). Вы можете использовать эту команду в двух режимах: относительный режим и абсолютный режим. В абсолютном режиме три цифры используются для установки основных разрешений.
При настройке разрешений рассчитайте необходимое вам значение. Если вы хотите установить чтение, запись и выполнение для пользователя, чтение и выполнение для группы, а также чтение и выполнение для других в файле /somefile, то вы используете следующую команду chmod:
Когда вы используете chmod таким способом, все текущие разрешения заменяются установленными вами разрешениями.
Если вы хотите изменить разрешения относительно текущих разрешений, вы можете использовать chmod в относительном режиме. При использовании chmod в относительном режиме вы работаете с тремя индикаторами, чтобы указать, что вы хотите сделать:
При изменении разрешений в относительном режиме вы можете пропустить часть «кому», чтобы добавить или удалить разрешение для всех объектов. Например, эта команда добавляет разрешение на выполнение для всех пользователей:
При работе в относительном режиме вы также можете использовать более сложные команды. Например, эта команда добавляет разрешение на запись в группу и удаляет чтение для других:
Расширенные права
Помимо основных разрешений, о которых вы только что прочитали, в Linux также есть набор расширенных разрешений. Это не те разрешения, которые вы устанавливаете по умолчанию, но иногда они предоставляют полезное дополнение. В этом разделе вы узнаете, что они из себя представляют и как их настроить.
Понимание расширенных прав SUID, GUID и sticky bit
Есть три продвинутых разрешения. Первое из них — это разрешение на установку идентификатора пользователя (SUID). В некоторых особых случаях вы можете применить это разрешение к исполняемым файлам. По умолчанию пользователь, запускающий исполняемый файл, запускает этот файл со своими собственными разрешениями. Для обычных пользователей это обычно означает, что использование программы ограничено. Однако в некоторых случаях пользователю требуются специальные разрешения, только для выполнения определенной задачи.
Рассмотрим, например, ситуацию, когда пользователю необходимо сменить пароль. Для этого пользователь должен записать свой новый пароль в файл /etc/shadow. Однако этот файл недоступен для записи пользователям, не имеющим прав доступа root:
Разрешение SUID может выглядеть полезным (и в некоторых случаях так оно и есть), но в то же время оно потенциально опасно. При неправильном применении вы можете случайно раздать права доступа root. Поэтому я рекомендую использовать его только с максимальной осторожностью. Большинству администраторов никогда не придется его использовать; вы увидите его только в некоторых файлах, где операционная система должна установить его по умолчанию.
Второе специальное разрешение — это идентификатор группы (SGID). Это разрешение имеет два эффекта. При применении к исполняемому файлу, он дает пользователю, который исполняет файл, разрешения владельца группы этого файла. Таким образом, SGID может выполнить более или менее то же самое, что SUID. Однако для этой цели SGID практически не используется.
Как и в случае с разрешением SUID, SGID применяется к некоторым системным файлам в качестве настройки по умолчанию.
Когда применяется к каталогу, SGID может быть полезен, потому что вы можете использовать его для установки владельца группы по умолчанию для файлов и подкаталогов, созданных в этом каталоге. По умолчанию, когда пользователь создает файл, его эффективная первичная группа устанавливается как владелец группы для этого файла. Это не всегда очень полезно, особенно потому, что у пользователей Red Hat/CentOS в качестве основной группы задана группа с тем же именем, что и у пользователя, и из которых пользователь является единственным участником. Таким образом, по умолчанию файлы, которые создает пользователь, будут групповыми для общего доступа.
Представьте себе ситуацию, когда пользователи linda и lori работают в бухгалтерии и являются членами группы account. По умолчанию эти пользователи являются членами частной группы, единственным членом которой они являются. Однако оба пользователя являются членами группы account, но также и в качестве параметра вторичной группы.
Ситуация по умолчанию состоит в том, что когда любой из этих пользователей создает файл, основная группа становится владельцем. Поэтому по умолчанию linda не может получить доступ к файлам, созданным lori, и наоборот. Однако, если вы создаете общий каталог группы (скажем, /groups/account) и убедитесь, что разрешение SGID применено к этому каталогу и что учет группы установлен как владелец группы для этого каталога, все файлы, созданные в этом каталоге и во всех его подкаталогах, также получают учет группы как владельца группы по умолчанию. По этой причине разрешение SGID является очень полезным разрешением для установки в каталогах общих групп.
Третий из специальных разрешений — sticky bit. Это разрешение полезно для защиты файлов от случайного удаления в среде, где несколько пользователей имеют права на запись в один и тот же каталог. Если применяется закрепленный sticky bit, пользователь может удалить файл, только если он является пользователем-владельцем файла или каталога, в котором содержится файл. По этой причине он применяется в качестве разрешения по умолчанию для каталога /tmp и может быть полезен также для каталогов общих групп.
Без sticky bit, если пользователь может создавать файлы в каталоге, он также может удалять файлы из этого каталога. В общедоступной групповой среде это может раздражать. Представьте себе пользователей linda и lori, которые оба имеют права на запись в каталог /data/account и получают эти разрешения благодаря участию в группе account. Поэтому linda может удалять файлы, созданные lori, и наоборот.
Когда вы применяете sticky bit, пользователь может удалять файлы, только если выполняется одно из следующих условий:
Применение расширенных прав
Чтобы применить SUID, SGID и sticky bit, вы также можете использовать chmod. SUID имеет числовое значение 4, SGID имеет числовое значение 2, а sticky bit имеет числовое значение 1.
Если вы хотите применить эти разрешения, вам нужно добавить четырехзначный аргумент в chmod, первая цифра которого относится к специальным разрешениям. Следующая строка, например, добавит разрешение SGID на каталог и установит rwx для пользователя и rx для группы и других:
Это довольно непрактично, если вам нужно посмотреть текущие права доступа, которые установлены, прежде чем работать с chmod в абсолютном режиме. (Вы рискуете перезаписать разрешения, если вы этого не сделаете.) Поэтому я рекомендую работать в относительном режиме, если вам нужно применить какое-либо из специальных разрешений:
В таблице обобщено все, что важно знать об управлении специальными разрешениями.
Пример работы со специальными правами
В этом примере вы используете специальные разрешения, чтобы членам группы было проще обмениваться файлами в каталоге общей группы. Вы назначаете ID-бит установленного идентификатора группы, а также stiky bit, и видите, что после их установки добавляются функции, облегчающие совместную работу членов группы.
1. Откройте терминал, в котором вы являетесь пользователем linda. Создать пользователя можно командой useradd linda, добавить пароль passwd linda.
3. Выполните su — lisa для переключения текущего пользователя на пользователя lisa, который также является членом группы sales.
5. Выполните touch lisa1 и touch lisa2, чтобы создать два файла, которые принадлежат пользователю lisa.
7. Выполните chmod g+s,o+t /data/sales, чтобы установить бит идентификатора группы (GUID), а также sticky bit в каталоге общей группы.
8. Выполните su — linda. Затем выполните touch linda3 и touch linda4. Теперь вы должны увидеть, что два созданных вами файла принадлежат группе sales, которая является владельцем группы каталога /data/sales.
Управление ACL (setfacl, getfacl) в Linux
Даже если расширенные права, которые обсуждались выше, добавляют полезную функциональность к тому, как Linux работает с разрешениями, это не позволяет вам предоставлять разрешения более чем одному пользователю или одной группе в одном файле. Списки контроля доступа предлагают эту функцию. Кроме того, они позволяют администраторам устанавливать разрешения по умолчанию сложным способом, при котором установленные разрешения могут различаться в разных каталогах.
Понимание ACL
Хотя подсистема ACL добавляет отличные функциональные возможности вашему серверу, у нее есть один недостаток: не все утилиты поддерживают ее. Следовательно, вы можете потерять настройки ACL при копировании или перемещении файлов, а программное обеспечение для резервного копирования может не выполнить резервное копирование настроек ACL.
Утилита tar не поддерживает ACL. Чтобы убедиться, что настройки ACL не будут потеряны при создании резервной копии, используйте star вместо tar. star работает с теми же параметрами, что и tar; он просто добавляет поддержку настроек ACL.
Отсутствие поддержки некоторыми инструментами не должно быть проблемой. Списки ACL часто применяются к каталогам как структурная мера, а не к отдельным файлам.
Поэтому их будет не много, а всего лишь несколько, примененных в умных местах файловой системы. Следовательно, восстановить исходные списки ACL, с которыми вы работали, относительно легко, даже если ваше ПО для резервного копирования их не поддерживает.
Подготовка файловой системы для ACL
Перед началом работы с ACL может потребоваться подготовить файловую систему для поддержки ACL. Поскольку метаданные файловой системы необходимо расширять, не всегда есть поддержка по умолчанию для ACL в файловой системе. Если при настройке списков ACL для файловой системы вы получаете сообщение «operation not supported», возможно, в вашей файловой системе отсутствует поддержка ACL. Чтобы это исправить, вам нужно добавить опцию acl mount в файле /etc/fstab, чтобы файловая система была смонтирована с поддержкой ACL по умолчанию.
Изменение и просмотр настроек ACL с помощью setfacl и getfacl
Команда setfacl имеет много возможностей и опций. Один вариант особенно важен, параметр -R. Если используется, опция делает настройку ACL для всех файлов и подкаталогов, которые в настоящее время существуют в каталоге, где вы устанавливаете ACL. Рекомендуется всегда использовать эту опцию при изменении списков ACL для существующих каталогов.
Работа с ACL по умолчанию
Одним из преимуществ использования списков ACL является то, что вы можете давать разрешения нескольким пользователям или группам в каталоге. Еще одним преимуществом является то, что вы можете включить наследование, работая с ACL по умолчанию. Установив ACL по умолчанию, вы определите разрешения, которые будут установлены для всех новых элементов, создаваемых в каталоге. Имейте в виду, однако, что ACL по умолчанию не меняет разрешения для существующих файлов и подкаталогов. Чтобы изменить их, нужно добавить и обычный ACL!
Пример управления расширенными правами с использованием ACL
В этом примере вы продолжите работу с каталогами /data/account и /data/sales, которые вы создали ранее. В предыдущих примерах вы гарантировали, что группа sales имеет разрешения на /data/sales, а группа account имеет разрешения на /data/account.
Сначала убедитесь, что группа account получает разрешения на чтение в каталоге /data/sales, а группа sales получает разрешения на чтение в каталоге /data/account.
Затем вы устанавливаете списки ACL по умолчанию, чтобы убедиться, что для всех новых файлов правильно установлены разрешения для всех новых элементов.
Установка прав по умолчанию с помощью umask
Выше вы узнали, как работать с ACL по умолчанию. Если вы не используете ACL, есть параметр оболочки, который определяет права по умолчанию, которые вы получите: umask (обратная маска). В этом разделе вы узнаете, как изменить разрешения по умолчанию с помощью umask.
Вы, наверное, заметили, что при создании нового файла устанавливаются некоторые разрешения по умолчанию. Эти разрешения определяются настройкой umask. Этот параметр оболочки применяется ко всем пользователям при входе в систему. В параметре umask используется числовое значение, которое вычитается из максимальных разрешений, которые могут быть автоматически установлены для файла; максимальная настройка для файлов — 666, а для каталогов — 777.
Однако некоторые исключения относятся к этому правилу. Вы можете найти полный обзор настроек umask в таблице внизу.
Из цифр, используемых в umask, как и в случае числовых аргументов для команды chmod, первая цифра относится к разрешениям пользователя, вторая цифра относится к разрешениям группы, а последняя относится к разрешениям по умолчанию, установленным для других. Значение umask по умолчанию 022 дает 644 для всех новых файлов и 755 для всех новых каталогов, созданных на вашем сервере.
Полный обзор всех числовых значений umask и их результатов в таблице ниже.
Простой способ увидеть, как работает параметр umask, выглядит следующим образом: начните с разрешений по умолчанию для файла, установленного на 666, и вычтите umask, чтобы получить действующие разрешения. Сделайте то же самое для каталога и его разрешений по умолчанию 777.
Есть два способа изменить настройку umask: для всех пользователей и для отдельных пользователей. Если вы хотите установить umask для всех пользователей, вы должны убедиться, что параметр umask учитывается при запуске файлов среды оболочки, как указано в /etc/profile. Правильный подход — создать сценарий оболочки с именем umask.sh в каталоге /etc/profile.d и указать umask, который вы хотите использовать в этом сценарии оболочки. Если в этом файле изменяется umask, он применяется ко всем пользователям после входа на сервер.
Работа с расширенными атрибутами пользователя
Это заключительный раздел о правах в Linux.
При работе с разрешениями всегда существует связь между объектом пользователя или группы и разрешениями, которые эти объекты пользователя или группы имеют для файла или каталога. Альтернативный метод защиты файлов на сервере Linux — работа с атрибутами.
Атрибуты выполняют свою работу независимо от пользователя, который обращается к файлу.
Как и в случае с ACL, для атрибутов файла может потребоваться включить параметр mount.
Это опция user_xattr. Если вы получаете сообщение «operation not supported» при работе с расширенными атрибутами пользователя, обязательно установите параметр mount в файле /etc/fstab.
Многие атрибуты задокументированы. Некоторые атрибуты доступны, но еще не реализованы. Не используйте их; они ничего вам не приносят.
Ниже приведены наиболее полезные атрибуты, которые вы можете применить:
A Этот атрибут гарантирует, что время доступа к файлу файла не изменяется.
Обычно каждый раз, когда файл открывается, время доступа к файлу должно быть записано в метаданные файла. Это отрицательно влияет на производительность; поэтому для файлов, к которым осуществляется регулярный доступ, атрибут A можно использовать для отключения этой функции.
a Этот атрибут позволяет добавлять, но не удалять файл.
c Если вы используете файловую систему, в которой поддерживается сжатие на уровне тома, этот атрибут файла гарантирует, что файл будет сжат при первом включении механизма сжатия.
D Этот атрибут гарантирует, что изменения в файлах записываются на диск немедленно, а не в кэширование в первую очередь. Это полезный атрибут в важных файлах базы данных, позволяющий убедиться, что они не теряются между файловым кешем и жестким диском.
d Этот атрибут гарантирует, что файл не будет сохранен в резервных копиях, где используется утилита дампа.
I Этот атрибут включает индексирование для каталога, в котором он включен. Это обеспечивает более быстрый доступ к файлам для примитивных файловых систем, таких как Ext3, которые не используют базу данных B-tree для быстрого доступа к файлам.
i Этот атрибут делает файл неизменным. Следовательно, в файл нельзя вносить изменения, что полезно для файлов, которые нуждаются в дополнительной защите.
j Этот атрибут гарантирует, что в файловой системе ext3 файл сначала записывается в журнал, а затем — в блоки данных на жестком диске.
s Перезаписать блоки, в которых файл был сохранен, на 0 с после удаления файла. Это гарантирует, что восстановление файла невозможно после того, как он был удален.
u Этот атрибут сохраняет информацию об удалении. Это позволяет разрабатывать утилиту, которая работает с этой информацией для спасения удаленных файлов.
