Методички(Зайков) / МУ_ЛР6_ОСиС

Методические указания к лабораторным работам составлены доц. А.В. Анцевым и обсуждены на заседании кафедры «Автоматизированные станочные системы» механикотехнологического факультета протокол № 1 от " 31 " августа 2011 г.

Зав. кафедрой________________А.Н. Иноземцев

Методические указания к лабораторным работам пересмотрены и утверждены на заседании кафедры «Автоматизированные станочные системы» механико-технологического факультета протокол №___ от "___"____________ 20___ г.

Зав. кафедрой________________ А.Н. Иноземцев

1 Цель и задачи работы

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

2 Основные теоретические сведения

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

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

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

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

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

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

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

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

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

∙некоторые программы в процессе выполнения могут поменять свой userID и, соответственно, получить права, которые сам пользователь не имел. Естественно, для того, чтобы программа могла это сделать, администратор должен "разрешить" ей такое поведение (подробнее об этом будет сказано ниже). Кстати, изменение userID'а делается не только, когда нужно "расширить" права программы, но и наоборот - "сузить" до прав какого-нибудь конкретного пользователя.

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

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

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

2.1.1 Владелец файла и группа "допущенных"

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

∙владелец (или хозяин) этого файла

∙группа "особо допущенных" к этому файлу

∙все остальные.

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

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

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

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

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

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

Самое время, рассмотреть конкретный пример.

Если у вас уже есть под рукой какой-нибудь Unix, наберите команду ls –l

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

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

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

Просто команда ls изображает их в более "человеческом" виде.

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

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

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

-rw-r--r-- 1 pascal 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 не сможет убедить систему, что файл является программой и его можно выполнять, пока не поставит в атрибутах этот бит.

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

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

Бит suid.

Бит suid. Расшифровывается как Set user ID, переводится как "установить идентификатор пользователя". Поскольку подходящего русскоязычного термина не существует, его обычно называют "суидный" бит, а файлы, на которых он установлен - "суидными".

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

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

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

"суидных" программ выполнять действия необходимые "взломщику".

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

Возвращаясь к разговору о "правах доступа", надо сказать, что у такого файла permissions выглядят как **s****** (если еще и установлен бит x для владельца файла) или как **S****** (если бит x не установлен). Однако, ставить suid бит на неисполняемые файлы обычно не имеет смысла.

Также, это бит не несет никакого смысла если его поставить на директорию, хотя никто не запрещает это сделать.

Бит sgid

Бит sgid. Расшифровывается как Set group ID, переводится как "установить идентификатор группы".

Эго смысл аналогичен смыслу предыдущего бита. Только меняется не идентификатор пользователя, а идентификатор группы. То есть, при выполнении этого файла он имеет такие права, как будто его запустил кто-то из группы, которая приписана к этому файлу.

Permissions такого файла выглядят как *****s*** (если установлен бит x для группы) или *****S** (если соответствующего бита x нет). Также как и в предыдущем случае, бит sgid для неисполняемых файлов никакого смысла не имеет.

А вот что касается бита sgid на директории...

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

Бит sticky

Бит sticky. Никак не расшифровывается, переводится как "липкий". Выглядит в permissions как ********t (если вместе с битом x для "всех

остальных") или ********T (если соответствующего бита x нет).

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

Применяют этот бит, обычно, на директориях, которые являются

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

Этот бит может ставиться также на исполняемые файлы. В этом случае он означает, что файл, даже после завершения работы, должен оставаться в памяти (конечно, не в ОЗУ, а в swap'е).

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

2.1.4 "Странные" сочетания битов доступа.

Для файлов

Обычно права на файл (например, для "всех остальных") устанавливаются

∙--- никаких прав (нельзя ни читать, ни изменять содержимое)

∙r-- только чтение

∙rw- и чтение и запись (изменение) файла.

Если файл является "исполняемым", то права могут выглядеть

∙--- опять же, никаких прав (читать нельзя, запускать нельзя)

∙r-x можно запустить файл-задачу на выполнение

∙rwx можно не только запустить, но и что-нибудь в нем поменять Остальные сочетания (например -w- или --x) кажутся бессмысленными. Однако, это не всегда так. Рассмотрим подробнее.

Права -w- означают, что пользователь из соответствующей категории не

может прочитать этот файл, но может в него писать.

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

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

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

Теперь посмотрим на исполняемые файлы.

Права --x на самом деле вполне законная комбинация. Она означает, что