Logo Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware
Бесплатный конструктор сайтов и Landing Page

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

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

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

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

VPS в России, Европе и США

Бесплатная поддержка и администрирование

Оплата российскими и международными картами

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

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

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

Типы файлов и права доступа

Поскольку любая Unix, и в частности FreeBSD - система многопользовательская, в ней предусмотрен механизм, ограничивающий доступ юзеров к файлам и директориям.

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

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

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

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

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

Не вдаваясь в подробности, можно сказать, что

  • каждый процесс имеет идентификатор юзера (userID). Обычно он совпадает с userID'ом того юзера, который запустил этот процесс.
  • процессы, которые запустились автоматически, тоже имеют userID, как будто их запустил реальный юзер. Чей именно userID получают эти программы обычно определяется теми программами, которые их стартуют (программа-загрузчик, cron, inetd и т.д.). В простейших случаях программы-"потомки" просто "наследуют" userID от программы-"родителя", но некоторые "родители" могут запускать программы с другим userID (не совпадающим с собственным).
  • некоторые программы в процессе выполнения могут поменять свой userID и, соответственно, получить права, которые сам юзер не имел. Естественно, для того, чтобы программа могла это сделать, администратор должен "разрешить" ей такое поведение (подробнее об этом будет сказано ниже). Кстати, изменение userID'а делается не только, когда нужно "расширить" права программы, но и наоборот - "сузить" до прав какого-нибудь конкретного юзера.
  • если процесс может изменять свой userID, то различают "реальный userID" и "эффективный userID" (есть еще "сохраненный userID"). Реальный userID - это идентификатор юзера, который запустил процесс (или userID процесса-"родителя"). А эффективный - это новый userID, который задача получила во время выполнения.
  • права на файл (или директорию) определяются по "эффективному userID" процесса. В простейшем случае, когда userID не меняется, "реальный" и "эффективный" userID'ы совпадают и можно говорить просто об userID'е процесса. Или даже просто о правах юзера (а не процесса) на файл.

Какие атрибуты файла определяют "праводоступа".

Все юзеры для каждого файла (или директории) делятся на три категории

  1. владелец (или хозяин) этого файла
  2. группа "особо допущенных" к этому файлу
  3. все остальные.

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

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

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

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

    И, наконец, в атрибутах файла есть некий набор битов или "флажков", который и указывает - кто и что может проделать с этим файлом. Этот набор называется permissions, что можно перевести как "допуски" или "права на доступ".

    Наберите команду

    ls -l

    (аналог команда dir в MS DOS) и вы увидите несколько строчек типа

    -rw-r--r-- 1 bob users 4297 23мар 17:37 list_us
    -rwxr-xr-x 1 bob users 1502 17мар 12:03 myProg
    -rw-r--r-- 1 bob users 5354 12мар 23:51 tmp.dat
    \________/ \_/ \___/ \__/ \__________/ \______/
    "права" владелец группа длина дата имяфайла
    

    В третьей колонке вы видите имя (login name) юзера - "хозяина" этих файлов (в данном случае это - bob). В четвертой колонке - название группы, приписанной также к этим файлам (в данном случае - users). И, наконец, в самой первой колонке (набор знаков типа "r", "w" и "-") сами permissions для всех трех категорий пользователей.

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

    Основные биты доступа (чтение/запись/выполнение)

    Рассмотрим подробнее - что представляют собой "права доступа".

    При распечатке содержимого директории (например, командой ls) каждая строчка имеет вид

    -rw-r--r-- 1 bob users 4297 13мар 21:45 files1
    

    причем нас интересует в данном случае только первая колонка.

    Она состоит из десяти знаков. Однако, самый первый знак не имеет отношения к permissions, а обозначает "тип этого объекта". Поскольку, в директории кроме файлов могут находиться поддиректории и, кроме того, в Юниксе, кроме обычных файлов существуют другие объекты ("линки", "очереди", "сокеты" и т.п.), которые также находятся в директориях и имеют атрибуты как и у обычных файлов. Так вот, первый символ как раз и показывает - что за объект мы видим, обычный файл (значок "-"), поддиректорию (значок "d") или еще какой-нибудь специфический объект ("l", "s", "p"...).

    Остальные девять знаков на самом деле представляют собой три группы по три символа. Каждая такая группа определяет права для какой-либо из трех категорий юзеров

    • первая группа - права "хозяина"
    • вторая группа - права "группы особо допущенных"
    • третья группа - права для "всех остальных"

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

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

    Для файлов.

    Первый бит, обозначается буквой "r" (read), и означает, что юзеру, подпадающему под соответствующую категорию, разрешается читать содержимое этого файла. То есть он может посмотреть содержимое файла, а также скопировать этот файл. Кстати, это не означает, что юзер сможет запустить его на выполнение (если это программа). Второй бит, обозначается буквой "w" (write) и разрешает писать в файл. То есть юзер сможет изменить содержимое файла (например, каким-нибудь редактором), дописать что-нибудь в конец или стереть все содержимое. Обратите внимание, этот бит еще не дает право удалить сам файл из директории или изменить ему название (это определяется правами на саму директорию), но дает возможность сделать этот файл пустым (нулевой длины) или скопировать в него содержимое другого файла (и тем самым "подменить" его). И, наконец, третий бит, обозначается буквой "x" (eXecute), позволяет запустить на выполнение этот файл, если он представляет собой программу или командный файл. Обратите внимание, что это также основной признак, по которому система догадывается о "запускаемости" этого файла. Часто начинающие пользователи составив какой-нибудь командный файл, забываю установить на него бит "исполнения" хотя бы для себя - владельца этого файла. В результате, при попытке запустить его, система сообщает, что "вы не имеете права" (выполнять этот файл). Естественно, что в данном случае причина не в том, что "злобный" администратор существенно "урезал" права этого юзера, а в том, что он сам забыл "наделить себя правом" (вполне законным).

    Для директорий.

    Первый бит ("r") разрешает читать оглавление этой директории, то есть список файлов и поддиректорий, находящихся в ней. Однако, этот бит еще не дает возможность зайти в эту директорию (командой cd) или получить доступ к содержимому, то есть читать/запускать/изменять файлы, даже если "права доступа" установленные на самих файлах это позволяют. Поэтому, само по себе "право чтения" директории практически бесполезно и этот бит, как правило ставиться только вместе с битом "x". Немного забегая вперед, рассмотрим сразу третий бит - "x". Для директорий он как раз означает, что юзер может получит доступ к "компонентам", то есть отдельным файлам и поддиректориям. Только при наличии это бита, система разрешит войти в эту директорию и выполнить какое-нибудь действие с файлом, если сами файлы ("права доступа" на них) это позволят. Кстати, обратите внимание, что если даже внутренние поддиректории имеют "нормальные" права для какой-то категории юзеров, а вышестоящая директория - нет (отсутствует бит "x"), то этим юзерам не удастся "занырнуть" в поддиректории, минуя вышестоящую. Система проверяет полный "путь" до конечной директории или файла (например, /usr/share/misc/fonts) и, если хотя бы один из компонентов этого пути не имеет соответствующего бита, то юзеру будет отказано в доступе. Наконец, бит "w", установленный на директории, позволяет изменять оглавление директории. То есть, разрешает создавать новые файлы (или копировать другие файлы в эту директорию), менять названия файлов и удалять файлы.

    Обратите внимание на "разделение полномочий" между теми permissions, которые стоят на файле и теми, которые на директории.

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

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

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

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

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

    Дополнительные биты доступа

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

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

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

     

Скидка до 20% на услуги дата-центра. Аренда серверной стойки. Colocation от 1U!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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