Logo Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware
Скидка до 20% на услуги дата-центра. Аренда серверной стойки. Colocation от 1U!

Миграция в облако #SotelCloud. Виртуальный сервер в облаке. Выбрать конфигурацию на сайте!

Виртуальная АТС для вашего бизнеса. Приветственные бонусы для новых клиентов!

Виртуальные VPS серверы в РФ и ЕС

Dedicated серверы в РФ и ЕС

По промокоду CITFORUM скидка 30% на заказ VPS\VDS

VPS/VDS серверы. 30 локаций на выбор

Серверы VPS/VDS с большим диском

Хорошие условия для реселлеров

4VPS.SU - VPS в 17-ти странах

2Gbit/s безлимит

Современное железо!

Несколько слов о "режиме безопасности".

Дело в том, что в FreeBSD система может находится на разных "уровнях безопасности". Существует четыре уровня

  • -1 - система безопасности выключена
  • 0 - система безопасности включена, но никаких ограничений нет
  • 1 - "режим безопасности", установлен ряд ограничений на работу с внешними устройствами и операции с флагами
  • 2 - "повышенная безопасность", еще больше ограничений, чем на уровне 1.

Подробнее о том, в чем заключаются ограничения и как меняются "уровни безопасности", можно прочитать в man init (отмечу только, что "по умолчанию" система стартует с уровнем -1, то есть "безопасность" выключена).

Для нас в данный момент важно только, что на уровне 1 и 2, даже суперюзеру (root'у) запрещено снимать флаги sappend и simmutable.

Естественно, это делается не для того, чтобы "защитить" систему от собственного администратора. Он все равно, при желании, сможет убрать эти флаги (и удалить/изменить соответствующие файлы). Правда, для этого ему придется перезагрузить систему, причем с консоли.

А вот "взломщик", проникший в систему, даже если каким-то образом и получит root'овские права, не сможет изменить "жизненно важные файлы" (если, конечно, они защищены флагом simmutable) или "почистить логи" (если они защищены флагом sappend), чтобы "замести следы" своего пребывания в системе.

С какими правами файл "рождается"

На самом деле вопрос поставлен не совсем корректно.

Дело в том, что новый файл появляется в результате работы какой-либо программы. В то же время, в Unix существуют системные функции, которые позволяют менять владельца файла, группу и права доступа. Естественно, программа, порождающая файл может вызывать эти функции и таким образом создать файл с любыми атрибутами.

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

Однако, большинство программ этими функциями не пользуются, поэтому можно сказать, что "в большинстве случаев" атрибуты создаваемых файлов все таки подчиняются нескольким простым правилам.

Какие же у только что созданного файла будут владелец, группа и права доступа?

Владелец

Владелец файла определяется "эффективным userID" программы, которая его создает. Это означает, что в большинстве случаев владельцем файла будет тот юзер, который его создал (естественно, с помощью какой-нибудь программы). Если же программа "суидная", то есть во время выполнения имеет права того юзера, которой является владельцем этой программы, то, соответственно, все файлы, порожденные этой программой, будут принадлежать хозяину программы, а не юзеру, который ее запустил.

Кстати, если даже в программе используются системные функции, которые меняют владельца файла, они сработают только в том случае, если ее "эффективный userID" будет userID root. То есть, если ее запустит юзер root или она является "суидной" и ее владелец root.

Другими словами, какие бы программы не использовал рядовой юзер (если, конечно, они не "суидные") он может создать файлы владельцем которых будет только он. "Подарить" файл кому-нибудь другому обычный юзер не может.

Группа

Группа создаваемого файла в FreeBSD определяется немного необычно. Она всегда "наследуется" от директории, в которой этот файл создается. То есть файл будет иметь ту же группу, которую имеет директория.

Обратите внимание, что юзер, создающий файл, может даже не являться членом этой группы. Это, конечно, не очень хорошо с точки зрения безопасности системы. Дело в том, что если юзер создаст исполняемый файл и потом поставит на него бит sgid, то этот файл при выполнении получит права группы, в которую сам юзер не входит и, возможно, получит доступ к таким файлам, куда его в обычной ситуации "не подпускают".

Правда, в FreeBSD такая ситуация предусмотрена и система просто не даст юзеру поставить бит sgid на файл, если юзер не является членом группы, которая "приписана" к файлу.

В других разновидностях Unix группа файлу, обычно, присваивается та, которая является "первичной" группой юзера, создающего файл (то есть, та, которая записана в его бюджете). А для того, чтобы группа, как и в FreeBSD "наследовалась" от директории, на самой директории должен стоять бит sgid.

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

Права доступа, которые будут у "свежеиспеченного" файла определяются параметром umask. Он задает - какие биты прав доступа НЕ НАДО выставлять в permissions.

Если это параметр равен нулю, то у всех создаваемых файлов права доступа будут одинаковые для всех категорий и выглядеть как rw-rw-rw. Директории (созданные, например, командой mkdir) будут иметь права доступа rwxrwxrwx. Такие же права доступа получатся и у исполняемых файлов, которые создают различные трансляторы (они, естественно, ставят биты "исполняемости" на результат своей работы).

Параметр umask можно посмотреть или изменить "одноименной" командой umask. Команда umask без аргументов просто показывает текущее значение этого параметра. А для того, чтобы поменять его, надо этой команде в качестве аргумента указать число, которое система "развернет" в соответствующие биты.

Если каждую группу из трех бит (что соответствует отдельной категории в правах доступа) рассматривать как двоичное число, то "свернув" их по отдельности в десятичные цифры мы получим число из трех цифр, которое и отражает значение всех битов в permissions. Точнее, получается не десятичное, а восьмеричное представление прав доступа, но, если вы мало знакомы с восьмеричной системой счисления, то можете просто рассматривать это число как три отдельных десятичных цифры.

Еще раз напоминаю, что биты в umask отмечают - какие биты прав доступа НЕ надо ставить при создании файла. То есть, если вы хотите, чтобы у категории "все остальные" вообще не было никаких прав, а "группе допущенных" не ставился бит разрешающий запись, то umask должна выглядеть как 027.

В FreeBSD по умолчанию в командных файлах, которые выполняются при входе в систему, у всех юзеров (включая root) вставлена команда, которая задает umask равной 022. То есть отменяются только биты разрешения записи для группы и "всех остальных". Если вас это не устраивает, вы можете изменить аргумент в соответствующем файле (обычно это файлы .login или .profile в домашней директории юзера) или поменять параметр umask в любой момент "вручную".

Как изменяются права доступа при копировании и перемещении файла.

Этот вопрос на самом деле более сложный, чем может показаться. Дело в том, что ответ на него зависит от многих условий

  • кто копирует (перемещает) файлы, root или обычный юзер
  • какие программы, и с какими ключами при этом используются
  • копируется файл "на пустое место" или там уже существует файл с таким именем

Тем не менее, опишем несколько общих правил, определяющих - какие права доступа могут получиться в результат.

Во-первых, при копировании (например, командой cp) создается новый файл. А при перемещении (например, командой mv) меняется только место расположения файла (и, возможно, имя).

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

Строго говоря, если копирование делает root, то эти правила действуют и для него (то есть, владельцем полученной копии будет root, группа будет взята от директории, а права выставятся в соответствии с umask). Однако, root может изменить поведение команды cp. У этой команды есть ключ (-p - сохранять permissions) который означает, что надо сохранить все атрибуты (владельца, группу и permissions) при копировании.

Обычный же юзер, даже используя ключ -p не сможет сохранить владельца и группу, но получит permissions такие же, как у оригинального файла. К тому же биты suid и sgid при этом также "сбрасываются".

Существует еще одна ситуация, когда при копировании сохраняются все атрибуты доступа. Это происходит, когда в "месте назначения" файл с таким именем уже существует. Собственно, в этом случае файл не создается, а только замещается его содержимое. Поэтому, даже если эту операцию проделает обычный юзер (естественно, для этого надо, чтобы ему было разрешено писать в существующий файл), все атрибуты, в том числе владелец и группа сохранятся. Правда, биты suid и sgid все равно "сбросятся".

А вот при перемещении файла все атрибуты сохраняются (даже "опасные" биты suid и sgid). Однако, не забудьте, что для того, чтобы обычный юзер смог переместить чужой файл, он должен иметь право записи и в ту директорию, куда файл переносится и в ту, откуда он переносится (поскольку, там запись о файле должна быть удалена). Такие ситуации в нормальной системе, как правило, не встречаются.

Как поменять...

Владельца и группу.

Во-первых, надо отметить - кто может поменять для файла (директории) владельца и группу.

Безусловно, это может сделать root.

Поменять владельца файла не может никто, кроме root.

А вот группу для файла может, также, поменять сам владелец файла, но только в том случае, если он сам является членом этой (новой) группы.

Для изменения владельца файла служит команда chown ("change owner"). С ее помощью можно заодно заменить и группу, хотя для изменения этого атрибута есть специальная команда chgrp ("change group").

Подробно об этих командах можно прочитать в соответствующих man-страницах (man chown и man chgrp). Поэтому, рассмотрим только их краткое описание.

Команда chown

Команда chown выглядит очень просто.

chown <новый владелец> <имя файла>

если же вы хотите поменять не только владельца, но и группу, то

chown <новый владелец>:<новая группа> <имя файла>

Кстати, никто не мешает указать в команде "старого" владельца, тогда изменится только группа.

Ну и, конечно, если вы хотите заменить владельца (группу) сразу на нескольких файлах, вместо имени файла можно указать подходящий "шаблон", например "*" (выполнить операцию для всех файлов в текущей директории).

Если же вы хотите, чтобы аналогичная операция была проделана не только в текущей директории, но и во всех "нижележащих" поддиректориях, вам поможет ключ -R (recursively).

Например, команда

chown -R bob:users *

заменит владельца на bob, а группу на users для всех файлов и поддиректорий, находящихся в текущей директории и "ниже", то есть в самих поддиректориях.

Команда chgrp

Команда chgrp очень похожа на предыдущую, только в качестве первого аргумента ей нужно указать название новой группы для файла (или файлов).

chgrp <новая группа> <имя файла>

Естественно, все, что было сказано о команде chown относительно выполнения ее над несколькими файлами и о ключе -R, также относится и к команде chgrp.

Права доступа (permissions)

Права доступа, кроме root может поменять также и владелец этого файла (директории). Кстати, обратите внимание, что хозяин файла может нечаянно установить такие биты доступа, что сам не сможет пользоваться этим файлом по назначению. Правда, никто не помешает ему же и исправить собственную ошибку.

Итак, для изменения прав доступа (permissions) служит команда chmod ("change mode"). В целом эта команда выглядит, как и предыдущие (которые меняют владельца игруппу).

chmod <что сделать> <имя файла>

Но, в отличии от предыдущих команд, второй аргумент ("что сделать") имеет несколько более сложный вид.

В нем можно выделить три части

"категория юзеров"
"операция"
"биты прав доступа"

u (user) владелец
g (group) группа
o (other) все остальные
a (all) все три категории
-
+
=
r
w
x
s или t

Как понятно из таблицы, первой задается категория юзеров (владелец, группа или "все остальные"). Причем, можно поставить сразу несколько букв, обозначив тем самым сразу несколько категорий. Например, go будет означать, что права меняются сразу и для группы и для "всех остальных". Если надо изменить права сразу для трех категорий, можно написать три буквы - ugo или одну букву a (все три категории).

Следом указывается "операция" (добавить права или наоборот - убрать). И, наконец, после "операции" один или несколько битов доступа, которые требуется изменить. Значение этих битов подробно рассматривалось выше, поэтому здесь не будем на них останавливаться.

Некоторых пояснений, наверное, требует "операция". Как можно догадаться, знаки "-" и "+" означают "убрать" или "поставить" соответствующие права.

А знак "=" означает сразу и то и другое. Дело в том, что если вы укажете, например o+x это будет означать - добавить бит x для категории "остальные", но никак не повлияет на биты r и w для этой же категории. А указав действие как o=rx, вы тем самым скажете системе - "установить биты r и x, и убрать бит w, если он там был".

Бит s имеет разный смысл (suid или sgid) в зависимости от того, в какой части permissions он находится. Поэтому, если вы хотите поставить именно suid бит, то "что сделать" должно выглядеть как u+s, а если вам нужен sgid, то - g+s. Sticky бит ставится командой chmod a+t ... .

Как видите, синтаксис этой команды достаточно гибкий (хотя и несколько усложненный). Кроме того, второй аргумент ("что сделать") может состоять из нескольких "действий" перечисленных через запятую.

Например, можно задать команду

chmod a=rx,u+w mydir

это будет означать - "для всех категорий права r-x, а для владельца еще и w (право записи)".

Кроме того, команда chmod (точнее - ее первый аргумент) имеет еще одну форму.

Поскольку, все биты доступа это действительно двоичные биты из одной ячейки, "продвинутый" пользователь может указать сразу число (в восьмеричном виде) которое должно получится после изменения прав.

Восьмеричное представление выбрано потому, что при переводе в него двоичного числа, каждая группа из трех бит "сворачивается" в одну цифру. Таким образом, вам надо просто указать три цифры, каждая из которых описывает отдельную категорию юзеров (точнее - права для этой категории). Например, permissions rwxr-xr-x можно представить в восьмеричном виде как 755. И, следовательно, такие права могут быть выставлены командой

chmod 755 myfile

Что касается выполнения этой операций над несколькими файлами или "рекурсивного" обхода всех поддиректорий, здесь все так же, как для команд chown, chgrp. В качестве имени файла может быть задан "шаблон", а для обхода всех поддиректорий используйте ключ -R.

И, конечно, обязательно прочтите man chmod.

Флаги.

Команда, которая ставит/убирает флаги - chflags ("change flags"). Формат ее достаточно простой

chflags <флаги> <имя файла>

Аргумент <флаги> - это название флага или нескольких флагов через запятую. Названия флагов описаны в разделе о флагах. Кроме того, эта команда понимает и сокращенные названия.

sappend - sappnd
uappend - uappnd
sunlink - sunlnk
uunlink - uunlnk
simmutable - schange или schg
uimmutable - uchange или uchg
arcived - arch
nodump не сокращается

Для того, чтобы убрать флаг, надо указать его название с префиксом no - nosappnd, nosunlnk, noschg и т.п.

Исключение составляет флаг nodump. Чтобы его убрать нужно сказать не nonodump, а просто dump.

Естественно, как и предыдущие команды chflags может применяться к нескольким файлам и "рекурсивно" обходить поддиректории (ключ тот же -R).

Сopyright © 2000. Андрей Фёдоров
http://www.anriintern.com/computer/freebsd/

Назад | Содержание | Вперед

 

Бесплатный конструктор сайтов и Landing Page

Хостинг с DDoS защитой от 2.5$ + Бесплатный SSL и Домен

SSD VPS в Нидерландах под различные задачи от 2.6$

✅ Дешевый VPS-хостинг на AMD EPYC: 1vCore, 3GB DDR4, 15GB NVMe всего за €3,50!

🔥 Anti-DDoS защита 12 Тбит/с!

VPS в 21 локации

От 104 рублей в месяц

Безлимитный трафик. Защита от ДДоС.

🔥 VPS до 5.7 ГГц под любые задачи с AntiDDoS в 7 локациях

💸 Гифткод CITFORUM (250р на баланс) и попробуйте уже сейчас!

🛒 Скидка 15% на первый платеж (в течение 24ч)

Новости мира IT:

Архив новостей

IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Информация для рекламодателей PR-акции, размещение рекламы — adv@citforum.ru,
тел. +7 495 7861149
Пресс-релизы — pr@citforum.ru
Обратная связь
Информация для авторов
Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
Copyright © 1997-2000 CIT, © 2001-2019 CIT Forum
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...