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

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

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

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

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

Для директорий обычно права доступа устанавливаются

∙--- никаких прав

∙r-x нормальные права для "посещения" директории, но без права изменения (создавать/удалять/переименовывать файлы)

∙rwx полный доступ (делай там что хочешь)

Имеет ли смысл устанавливать какие-либо другие сочетания?

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

Комбинация r-- даст возможность получить список файлов в этой директории, например командой ls, и не более того. Причем посмотреть можно будет только имена файлов, а такие подробности, как владелец/группа/permissions будут недоступны. В такую директорию нельзя "войти" командой cd. И, даже если внутри нее поддиректории имеют вполне нормальные права доступа (например r-x), попасть в них будет невозможно.

Комбинации -w- и rwимеют еще меньше смысла. Все равно, изменить что-нибудь в директории с такими правами доступа не удастся.

А вот сочетания --x и -wx на самом деле вполне осмысленны.

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

Аналогично и с поддиректориями. Если вы не хотите, чтобы кто-нибудь просто "бродя" по вашим директориям наткнулся на директорию с "секретным" содержанием (например sex-pictures :-), но, в тоже время, не против чтобы некоторые близкие друзья могли туда "захаживать" и знакомится с новыми пополнениями, "спрячьте" свои "приватные" директории в директорию (например private) с доступом --x. Тогда ваши друзья смогут попасть в нужную поддиректорию, указав полный путь (cd private/sex-pictures), а случайные

посетители ее просто не найдут (если, конечно, этот посетитель не root). Конечно, "секретность" в этом случае будет не полной, поскольку, если

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

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

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

∙владелец - полные права (rwx)

∙группе доверенных лиц - тоже самое, но без права изменения (r-x)

∙всем остальным - никаких прав (---)

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

Но в данном случае речь не об этом. Что будет, если "всем остальным" дать доступ, пусть и ограниченный, а для группы "особо приближенных" - наоборот убрать (выглядеть это будет примерно так - rwx---r-x)?

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

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

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

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

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

файл создает".

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

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

Владелец

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

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

"эффективный userID" будет userID root'а. То есть, если ее запустит пользователь root или она является "суидной" и ее владелец root.

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

Группа

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

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

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

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

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

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

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

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

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

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

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

∙кто копирует (перемещает) файлы, root или обычный пользователь

∙какие программы и с какими ключами при этом используются

∙копируется файл "на пустое место" или там уже существует файл с таким именем

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

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

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

Строго говоря, если копирование делает root, то эти правила действуют и

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

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

Если же вы хотите, чтобы аналогичная операция была проделана не только в текущей директории, но и во всех "нижележащих" поддиректориях,

вам поможет ключ -R (recursively).

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

chown -R vasia:users *

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

Команда chgrp

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

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

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

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

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

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

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

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

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

Как понятно из таблицы, первой задается категория пользователей (владелец, группа или "все остальные"). Причем, можно поставить сразу несколько букв, обозначив тем самым сразу несколько категорий. Например, 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.

3 Задание на работу