Наследование прав доступа от родительского каталога
Есть директория /srv/sites/domain.ltd/html принадлежащая пользователю и группе apache:apache и имеющая права 6770 (rwsrws—). Есть юзер iskatel, который входит в группу apache и он создаёт в этой директории файл, скажем, index.html. Файл автоматом получает принадлежность к юзеру iskatel и группе apache. А я вот ожидал другого результата, ведь наличие suid и sgid битов на каталоге должно приводить к тому что файл у родительского каталога будет наследовать и группу и юзера, то есть юзер должен быть apache. Почему так?
Потому что suid не работает для каталогов.
Бит setuid, установленный для директорий, игнорируется в большинстве версий Unix[источник не указан 1468 дней].
А какие тогда есть способы получить желаемое?
Cоздавайте файл пользователем apache. Но полагаю chown будет удобнее.
Если оба юзера входят в группу, являющуюся группой-владельцем этого файла, то сможет.
P.S. Надо поэксперементировать с этим )
Каждый раз делать chown? А представь, что юзеру права рута, чтобы использовать chown, не даются.
Операционные системы Astra Linux
Оперативные обновления и методические указания
Операционные системы Astra Linux предназначены для применения в составе информационных (автоматизированных) систем в целях обработки и защиты 1) информации любой категории доступа 2) : общедоступной информации, а также информации, доступ к которой ограничен федеральными законами (информации ограниченного доступа).
1) от несанкционированного доступа;
2) в соответствии с Федеральным законом от 27.07.2006 № 149-ФЗ «Об информации, информационных технологиях и о защите информации» (статья 5, пункт 2).
Операционные системы Astra Linux Common Edition и Astra Linux Special Edition разработаны коллективом открытого акционерного общества «Научно-производственное объединение Русские базовые информационные технологии» и основаны на свободном программном обеспечении. С 17 декабря 2019 года правообладателем, разработчиком и производителем операционной системы специального назначения «Astra Linux Special Edition» является ООО «РусБИТех-Астра».
На web-сайтах https://astralinux.ru/ и https://wiki.astralinux.ru представлена подробная информация о разработанных операционных системах семейства Astra Linux, а также техническая документация для пользователей операционных систем и разработчиков программного обеспечения.
Мы будем признательны Вам за вопросы и предложения, которые позволят совершенствовать наши изделия в Ваших интересах и адаптировать их под решаемые Вами задачи!
Репозитория открытого доступа в сети Интернет для операционной системы Astra Linux Special Edition нет. Операционная система распространяется посредством DVD-дисков.
Информацию о сетевых репозиториях операционной системы Astra Linux Common Edition Вы можете получить в статье Подключение репозиториев с пакетами в ОС Astra Linux и установка пакетов.
В целях обеспечения соответствия сертифицированных операционных систем Astra Linux Special Edition требованиям, предъявляемым к безопасности информации, ООО «РусБИтех-Астра» осуществляет выпуск очередных и оперативных обновлений.
Очередные обновления (версии) предназначены для:
Оперативные обновления предназначены для оперативного устранения уязвимостей в экземплярах, находящихся в эксплуатации, и представляют собой бюллетень безопасности, который доступен в виде:
Ввиду совершенствования нормативно-правовых документов в области защиты информации и в целях обеспечения соответствия информационных актуальным требованиям безопасности информации, а также обеспечения их долговременной эксплуатации, в том числе работоспособности на современных средствах вычислительной техники, рекомендуется на регулярной основе планировать проведение мероприятий по применению очередных и оперативных обновлений операционной системы.
Linux наследование прав при создании файла
В данной статье подробно рассмотрим права доступа к каталогам и файлам в Linux. А также расскажу о том, как можно изменить права и владельца на файлы и директории в Linux.
Первое, что я хотел бы рассмотреть, это каким образом можно просмотреть права доступа на файлы и каталоги.
Просмотр прав доступа на файлы и каталоги в Linux.
Прежде, чем двигаться далее, советую прочитать первую статью (если Вы этого не сделали, конечно) данного цикла про навигацию в терминале.
Для статьи я создал несколько файлов и каталогов в домашней папке.
Для того, чтобы просмотреть права доступа на файлы и каталоги в нужной директории, переходим в неё и выполняем команду:
У нас будет выведено следующее сообщение в терминале:
Как видно, для наших файлов и каталогов вывелась подробная информация.
Слева отображены права доступа на файл и директорию вида:
Чуть ниже подробно разберём это «непонятную» надпись, а пока двигаемся дальше.
Для того, чтобы просмотреть права доступа на определенный файл, нужно ввести следующую команду:
Вот как это выглядит:
Для того, чтобы просмотреть права доступа на определенный каталог, вводим следующую команду:
Выглядит это следующим образом:
Для того, чтобы просмотреть права доступа на директории и файлы рекурсивно внутри каталога, нужно ввести следующую команду, перейдя в нужный каталог:
либо ввести каталог:
Выглядит это следующим образом:
Расшифровка «символьной формы» прав доступа на каталоги и файлы в Linux.
После выполнения команд из первого пункта у нас выдавалось сообщение вида:
Будем использовать в качестве примера в этом пункте.
Это символьная форма прав доступа в Linux. Давайте разберем её подробно.
Данное сообщение состоит из 10 символов.
Первый символ обозначает тип данных.
Данный символ может быть следующим:
В большинстве случаев это будет:
| — | обычный файл; |
| d | директория/каталог/папка (directory); |
| l | символическая ссылка (link). |
Но может быть следующим:
| b | файл блочного устройства (block); |
| c | файл символьного устройства; |
| s | доменное гнездо (socket); |
| p | именованный канал (pipe). |
Следовательно, в нашем случае это директория (каталог, папка).
Следующие 9 символов обозначают права доступа.
Данные 9 символов состоят из трех групп:
У этих трёх групп одинаковая комбинация символов, то есть:
Что же они обозначают?
Очень легко запомнить:
| r | read, то есть, право доступа на чтение файла или директории. |
| w | write, то есть, право на изменение и удаление файла или директории. |
| x | eXecute, то есть, право на запуск файла как программы или вход в директорию. |
Всегда располагаются в таком порядке:
Если вместо какого-то символа идёт тире (минус), к примеру:
то это значит, что отсутствуют права на изменение и удаление файла или директории.
то это обозначает, что отсутствуют права на изменение и запуск файла или директории. Доступен только просмотр.
Таким образом, из нашего примера:
Как видите, ничего сложного нет.
Определение владельца и группы файла или директории.
Но у Вас может возникнуть закономерный вопрос о том, а как же узнать, кто именно является владельцем файла и какая группа?
Те же самые команды из первого пункта:
Как видно на скриншоте:
Следовательно, если пользователь не владелец файла, но входит в группу, то у него будут права на файл или директорию этой самой группы.
В Nautilus (файловом менеджере Ubuntu), можно нажать правой кнопкой мыши на файле, открыть свойства, перейти на вкладку «Права» и увидеть:
Здесь в графическом режиме видны права доступа, владелец и группа. И если Вы являетесь владельцем файла или директории, то Вы можете изменять права доступа.
Подробно разобрали просмотр прав доступа на файлы и каталоги Linux.
Теперь приступим к их изменению в терминале.
Изменение прав доступа на файлы и каталоги в Linux в символьном режиме.
Для того, чтобы изменить права доступа, воспользуйтесь следующим шаблоном:
Вместо persons нужно использовать совокупность символов или один из:
Этот символ обозначает субъект, которому будут назначены, удалены или изменены права.
Вместо Operator, может быть один из следующих символов:
| + | «плюс», добавляем нужные права. |
| — | «минус», удаляем нужные права. |
| = | «равно», устанавливаем нужные права. |
Этот символ обозначает оператор, от которого зависит, будут ли добавлены, удалены или установлены нужные права, которые последуют за оператором.
Вместо Rights перечисляем символы прав доступа:
Здесь идёт цепочка из трёх перечисленных символов, но в определённом порядке rwx. Но при этом, не нужно указывать тире для пропуска. Примеры: rwx, rw, wx, rx, r, w, x.
Вместо имяфайлаилиимядиректории указываем путь к файлу или директории.
То есть, если нужно изменить права всех файлов и папок внутри указанной нами директории, то после chmod просто указываем параметр -R. Выглядит это следующим образом:
Важно.
Если Вы не являетесь владельцем файла или директории или у вас нет прав на изменение файла, то нужно будет использовать права суперпользователя:
Приступим к практике. Разберём примеры.
1. Убираем права для группы на изменение файла:
2. Убираем права на чтение у группы и всех остальных:
3. Добавим для группы права на чтение и изменение:
4. Изменим рекурсивно права на файлы и директории внутри нужной директории. Отменим, к примеру, все права у остальных пользователей и групп:
Вы, наверное, зачастую видели команду:
Это значит, что мы даём права на выполнение данного файла как программы всем.
Это аналогично следующим командам:
То есть, если мы хотим изменить права файл или директорию для всех, мы можем не писать кому. Просто оператор и права.
Изменение прав доступа на файлы и каталоги в абсолютном режиме.
Есть более простой способ изменение прав доступа на файлы и каталоги в Linux. Это изменение прав доступа в числовом представлении.
Думаю, что многие из вас видели на форумах или сайтах о Linux советы по изменению прав, вида:
Вы их выполняли в терминале. А многие из вас задумывались, что это за «магические цифры». Но на самом деле никакая это не магия.
Давайте разберем, что же значат эти цифры.
Итак, у нас есть комбинация прав доступа на директорию:
А теперь делим на группы:
Теперь преобразуем в двоичном виде наши права доступа:
Следовательно, наша комбинация будет выглядеть следующим образом:
А теперь переведем из двоичной в восьмеричную систему исчисления:
Вот и получили наше «магическое» число 775.
Более проще запомнить:
| r | это 4 |
| w | это 2 |
| x | это 1 |
Каждая цифра обозначает определенную группу:
Просто прибавляем цифры. К примеру, нам нужно чтение r и изменение w. Прибавляем 4+2, получаем 6.
Если хотим выдать полные права только владельцу файла, а остальным убрать все:
Вот так меняются права в абсолютном (числовом) режиме.
Изменение владельца и группы файла или каталога.
Для изменения владельца и группы файла или каталога есть команда chown.
Используется следующий шаблон выполнения данной команды chown:
Если хотим изменить только группу, то шаблон следующий:
Если хотим изменить только владельца, то шаблон следующий:
В принципе, ничего сложного.
Чтобы узнать имя текущего пользователя, используется команда:
Чтобы узнать в каких группах состоит текущий пользователь:
Получить список пользователей:
Получить группы конкретного пользователя (вместо user_name ввести имя пользователя):
Давайте сменим владельца у файла на root:
Вот таким образом меняются владельцы и группы.
Расширяем права доступа в Linux с помощью ACL
Архив номеров / 2005 / Выпуск №11 (36) / Расширяем права доступа в Linux с помощью ACL
Строка default:mask показывает маску эффективных прав, которую не могут превысить пользователь или группа. Используя маску, можно задать общие права для всех пользователей и групп, например: Как видите, для пользователя sergej и группы sales установлены отличные от всех остальных права. При этом, если вы попытаетесь установить параметры для несуществующего пользователя или группы, утилита завершит выполнение с ошибкой. Кстати, установить новые разрешения в файловой системе, смонтированной без опции ACL, не получится.
Проверим наследование атрибутов. И в качестве вывода получим: default:group: sales: rwx Теперь пробуем создать файл в каталоге: Пользователь sergej и группа sales унаследовали права. Убедимся, что стандартные права доступа все еще существуют. -rw-rw-r— 1 root root 0 Окт 22 16:10 test_file В некоторых дистрибутивах команда ls для файлов и каталогов, в которых используется ACL, дополнительно выводит знак +, например drwxr-xr-x+. От чего зависит присутствие плюса в выводе, мне, к сожалению, неизвестно. Команда chmod также работает с такими файлами и каталогами, только теперь изменяются не права доступа пользователей, а значение маски доступа. Сохранение расширеных прав при копировании и перемещении В документации сказано, что при копировании и перемещении расширенные права доступа должны сохраняться, что сейчас и проверим: default:group: sales: rwx Все атрибуты на месте, т.е. команда mv перемещает файлы вместе с привязанными к ним списками контроля доступа. Теперь переместим тестовый каталог в раздел смонтированный без ACL и проверим разрешения: # mv test_acl /home/sergej/ Из увиденного можно сделать однозначный вывод: без указания при монтировании дискового раздела опции ACL списки контроля доступа работать не будут. Утилита getfacl при использовании на таком разделе выведет стандартные права доступа. Теперь сделаем копию файла в текущем каталоге: # apt-get install acl attr # cp test_acl_file test_acl Разрешения изменились и соответствуют файлу test_file, который был создан в этом каталоге. Теперь копируем в этот каталог тестовый файл. # cp test_acl_file dir И еще один интересный момент, о котором стоит упомянуть. Операции копирования и перемещения были проделаны и другими инструментами. Результат эксперимента с Midnight Commander совпал с результатом использования утилит ср и mv, а вот Konqueror при перемещении не сохранил расширенные права. Почти аналогично ведут себя kate и Kwrite. Если сохранять результат в текущий файл, то права сохраняются, а если в новый, то теряются. Все это выглядит несколько странно, потому что за операции с правами по идее должно отвечать ядро. Как видите, при использовании ACL необходимо очень тщательно отбирать и инструменты, т.к. при работе с некоторыми утилитами права теряются. Ошибка может привести к тому, что любая «неправильная» утилита может сделать бесполезной всю безопасность с ACL. Некоторые опции утилит setfacl и getfacl При помощи связки getfacl/setfacl можно сохранить и восстановить списки контроля доступа, это может понадобиться при архивировании данных или переносе в другую систему. Если для некоторого файла или каталога требуется установить разрешения, которые сходны с уже имеющимися, то можно поступить так (опции, написанные с заглавной буквы, применяются при использовании в качестве ввода результата работы другой утилиты). Установленную для каталога маску доступа, используемую по умолчанию, можно изменить так: Поддержка ACL в NFS и Samba Поддержка ACL в NFS еще не закончена, но 4 версия протокола уже поддерживает стандартизованные удаленные вызовы процедур на получение и установку разрешений ACL. Причем правильно обрабатывает запросы демон, работающий в пространстве ядра. Демон, работающий в пространстве пользователя, поддерживает только вторую версию протокола и неправильно обслуживает запросы. Клиенты, работающие со второй версией протокола, используют традиционные девять бит, поэтому при передаче информация об ACL искажается. Уже в третьей версии клиенты для запроса прав пользователя опираются на вызов ACCESS, и точное разрешение этого вопроса предоставляется клиенту. Хотя стоит отметить, что существуют решения, позволяющие использовать ACL поверх NFS, но это тема другого разговора. Пока же разработчики рекомендуют использовать ACL при работе с NFS осторожно. smbcacls //server/share filename [options] Кроме стандартных rwx для файлов и каталогов можно установить дополнительные права: Разработчикам проекта Trustees [2] схема, применяемая в POSIX ACL, показалась неудобной. Для поддержания в рабочем состоянии системы POSIX ACL требуются инструменты, позволяющие рекурсивно обходить каталоги, необходимые для установки или изменения разрешений. Кроме того, при большом количестве объектов такая схема требует особого внимания и контроля. Схема, используемая в Novell Netware, несколько проще, т.к. для установки разрешений используется один конфигурационный файл, который будет полностью контролироваться системным администратором и не потребует разработки дополнительного инструментария либо сложных скриптов. Именно такой подход применен в trustees. В июне 2005 года стал наконец доступен стабильный релиз новой версии 3.0, о котором пойдет речь далее. Trustees позволяет дать доступ пользователю или группе пользователей к дереву каталогов, а не единственному файлу, что является отходом от стандарта POSIX ACL. В принципе в большинтсве случаев создание каталога и определение к нему доступа, является типичной задачей, доступ к отдельному файлу регулируется реже и является частным решением. Поэтому такой подход вполне себя оправдывает. К тому же в этом случае не требуется установка тысяч разрешений для каждого файла, что может привести при невнимательности к ошибке, и теперь администратору легче контролировать разрешения т.к. все ограничения для каталога и подкаталогов записываются в одной строке. Кроме того в этом случае снимается зависимость от используемой файловой системы и сервиса. Поэтому Trustees в принципе можно использовать при работе с Samba, ftp, NFS, http. Кроме принципа организации доступа Novell Netware в проекте использованы наработки Java Security. В архиве размером 26.3 Кб содержатся патчи к ядрам версии 2.6 (2.6.8-2.6.13-rc3), исходные тексты для компиляции модуля и утилиты settrustees. Trustees можно скомпилировать вместе с ядром или установить как модуль. Для первого варианта необходимы исходные тексты ядра с номером версии, для которого имеется патч (при отсутствии такового можно попробовать ближайший по номеру, с большой вероятностью он будет работать). Далее поступаем обычным образом: patching file security/trustees/trustees.h patching file security/trustees/init.c patching file security/trustees/funcs.c patching file security/trustees/fs.c patching file security/trustees/Kconfig patching file security/trustees/trustees_private.h patching file security/trustees/Makefile patching file security/trustees/security.c patching file security/Kconfig patching file security/trustees/Kbuild patching file security/Makefile
Рисунок 2. После пропатчивания в Security options появится новый пункт Trustees ACLS, который необходимо включить После чего ядро компилируется и устанавливается обычным образом. При установке в качестве модуля необходимо наличие исходных текстов рабочего ядра (оно должно быть обязательно собрано с опцией CONFIG_SECURITY). Далее переходим в каталог module распакованного архива trustees и вводим make install. Если при компиляции не будут найдены исходные тексты, то следует указать их местонахождение вручную. # make KDIR=/usr/src/linux-2.6.11 install После успешной компиляции модуля переходим в подкаталог src и вводим make, получившийся исполняемый файл settrustees копируем в /usr/sbin, чтобы он был доступен только пользователю root. Теперь все готово к работе. Загружаем модуль modprobe trustees.ko, либо перегружаем систему с новым ядром. Обратите внимание на флаг I во втором примере. С его помощью указываются на чувствительные к регистру букв устройства. Иначе для //smb/share/DIR и //smb/share/dir будут установлены одни и те же права доступа. Каталоги, находящиеся на определенном устройстве, описываются без указания точки монтирования, т.е. если прописывается каталог /home/sergej, а раздел /home смонтирован на /dev/hda5, то указывается он так: В качестве указания параметров доступа используются следующие флаги: Пустой параметр означает запрет всех полномочий. Вместе с флагами могут использоваться следующие модификаторы, которые могут устанавливаться, например для временного переопределения прав: Пустые линии игнорируются, знак решетки (#) означает комментарий. Для примера занесем в файл информацию, запрещающую пользователю sergej запись в каталог, находящийся на разделе с файловой системой FAT, традиционно имеющий права доступа 777, и ограничимся одним уровнем рекурсии. Теперь создаем тестовый каталог и указываем модулю на необходимость монтирования виртуальной файловой системы. Так монтируются каталоги индивидуально, если требуется смонтировать все каталоги из файла /etc/trustees.conf, то вызывается утилита settrustees. # mount | grep trusteesfs
Пробуем создать файл :
Что и следовало ожидать. Стоит отметить, что создание файла на уровень выше или ниже тестового каталога пройдет без проблем. Чтобы остановить использование виртуальной файловой системы, достаточно набрать: Более жизненный пример. Позволим веб-серверу считывать данные из каталога с документами, а веб-мастерам, кроме того и изменение файлов: Итак, применение ACL позволяет использовать более сложные модели доступа, чем традиционная реализация, применяемая в UNIX-системах. Используя ACL, даже при небольшом количестве пользователей администратор может существенно упростить процесс распределения полномочий пользователей. Но на сегодняшний день без боязни можно использовать лишь консольные утилиты, остальные нуждаются в предварительном тестировании перед использованием в промышленной среде. |
СЕРГЕЙ ЯРЕМЧУК, фрилансер. Автор более 800 статей и шести книг. С «СА» с первого номера. Интересы: сетевые технологии, защита информации, свободные ОС
