Главная » Программирование для UNIX » Права доступа файлов UNIX

0

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

1        В качестве примера автор  приводит дамп  файла каталога в том виде, какой мы  получили бы в старых версиях UNIX, использующих s5fs (файловую систему, изначально применявшуюся в UNIX  System V). Реализации фай ловых систем современных версий отошли от записей фиксированной дли ны (в них формат файла каталога более сложный) и не ограничивают длину имени файла 14-ю  символами, как это было когда-то. Так, FFS  (Fast File  System), появившаяся впервые в BSD 4.2, допускает уже 255-символьные имена файлов. – Примеч. науч. ред.

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

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

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

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

В процессе регистрации в системе пользователь  вводит имя, а затем при помощи пароля подтверждает, что он именно тот, за кого себя выдает. Это имя  называется регистрационным идентификатором (login5 id).   В  действительности  система  опознает  пользователя  по  номеру uid –   идентификатору   пользователя.  Фактически,   несколько  регистрационных идентификаторов могут  иметь одно  и то же значение uid, что не позволяет системе отличить их друг от друга, хотя это случай  довольно редкий и нежелательный с точки зрения безопасности.

1        Если  быть  более  точным, то права суперпользователя будут  делегированы системой любому процессу пользователя,  эффективный пользовательский идентификатор которого равен нулю. Но имя  учетной записи пользователя и его  идентификатор,  получаемый системой из  этой  учетной записи при  входе  пользователя в систему, никак не связаны в действительности. Поэтому  вполне может оказаться, что в какой-то системе администратор поменял имя регистрационной записи с нулевым идентификатором на что-то  другое, отличное от root. Однако назначение такого имени для учетной записи  суперпользователя – многолетняя традиция, а слова  «root» и «суперпользователь» воспринимаются как синонимы. – Примеч. науч. ред.

Помимо идентификатора uid  пользователю присваивается идентифи5 катор группы (group5id),  определяющий некоторый класс пользователей. Во многих системах обычные пользователи (в отличие от таких, как root)  помещаются в  одну  группу, называемую  «остальные» (other), но возможно, что в вашей системе приняты другие правила. Фай ловая система, а значит и система UNIX  в целом, на основе  значений uid  и group-id, выданных пользователю, определяет, какие действия ему разрешены.

Пароли хранятся в файле /etc/passwd; там  же находится вся регистрационная информация каждого из  пользователей. Можно узнать свои значения uid и group-id так же, как это делает система, найдя свое имя  в файле /etc/passwd:

$ grep  you /etc/passwd

you:gkmbCTrJ04COM:604:1:Y.O.A.People:/usr/you:

$

Поля в файле паролей разделены двоеточиями и расположены в таком порядке (в соответствии с passwd(5)):

login5id:encrypted5password:uid:group5id:miscellany:login5directory:shell

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

Поле  shell,  определяющее оболочку, часто остается пустым, подразумевая оболочку по умолчанию, то есть /bin/sh. Поле  miscellany может содержать произвольные данные, часто  в нем  хранят имя, адрес  или  номер  телефона.

Обратите внимание на то,  что пароль, занимающий второе  поле, хра нится в  зашифрованном виде. Любой  пользователь  может прочитать этот  файл, и если  бы пароль хранился незашифрованным, узнать его мог бы кто угодно. Когда  пользователь вводит свой пароль в программе login, та шифрует его и сравнивает результат с образцом из /etc/passwd. В случае совпадения разрешен вход в систему. Такой механизм эффективен благодаря тому, что алгоритм шифрования работает достаточно быстро, а дешифрование требует значительных усилий. Например, пароль ka–boom может в зашифрованном виде выглядеть как gkmbCTrJ04COM, но восстановить по такой строке оригинал весьма непросто.

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

Команда ls, запущенная с параметром –l, выводит, кроме прочего, информацию о правах доступа:

$ ls -l /etc/passwd

–rw–r––r–– 1 root              5115 Aug  30 10:40  /etc/passwd

$ ls -lg /etc/passwd

–rw–r––r–– 1 adm                  5115 Aug  30 10:40  /etc/passwd

$

В этих  двух  строках содержится следующая информация: файл /etc/ passwd принадлежит  пользователю root   из  группы adm,  имеет   длину 5115  байт, время последнего изменения 10:40 30 августа, имеет  одну ссылку (одно имя  в файловой системе; ссылки обсуждаются в следующем разделе). Некоторые версии ls выводят информацию одновременно о пользователе и о группе.

В строке –rw–r––r–– представлены сведения о правах доступа к файлу. Первый знак – говорит о том,  что это обычный файл. Если  бы это был каталог, то в первой позиции находился бы символ d. Следующие три  символа показывают  права владельца (определяемые по  его  uid)  на чтение, запись и выполнение. Символы rw– означают, что root  (владелец файла) может читать и писать, но не может выполнять этот файл. У исполняемых файлов вместо прочерка должен стоять символ x.

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

/etc/passwd .

Файл /etc/group содержит имена групп и их идентификаторы и опреде ляет принадлежность пользователей к группам. В /etc/passwd опреде лена  только первоначальная группа, которая назначается при  регистрации; команда newgrp изменяет текущую группу пользователя.

Любой пользователь с помощью команды

$ ed /etc/passwd

может редактировать файл паролей, но только root  может сохранить сделанные изменения. Возникает вопрос, как пользователь может изменить свой  пароль, если  для  этого  ему  необходимо редактировать файл паролей? Это можно сделать при  помощи команды passwd, нахо дящейся обычно  в каталоге /bin:

$ ls -l /bin/passwd

–rwsr–xr–x  1 root            8454 Jan    4   1983 /bin/passwd

$

(Учтите, что /etc/passwd представляет собой текстовый файл с регистрационной информацией, а /bin/passwd, расположенный в другом каталоге, является  исполняемой  программой, позволяющей изменить информацию о пароле.) В данном случае права  доступа определяют, что команда доступна для выполнения всем,  но только root  может ее изменить. Символ s вместо  x в поле прав  на исполнение для  владельца говорит о том, что  команда во время выполнения приобретает  права своего владельца, в данном случае root. А так как /bin/passwd получает при  исполнении  идентификатор пользователя root, любой  пользователь с помощью этой команды может изменить файл паролей.

Назначение атрибута SUID (set-uid) – простая и изящная идея,1 решающая ряд проблем безопасности. Например, автор  игровой программы может присвоить ей исполнительный идентификатор владельца с тем, чтобы  она  могла обновлять текущий  счет  в  файле, защищенном от прямого вмешательства других пользователей. Но концепция set-uid таит в себе и потенциальную опасность. Программа /bin/passwd должна работать правильно; в противном случае она может, действуя от имени суперпользователя, уничтожить системную информацию. Если права доступа к ней установлены в –rwsrwxrwx, то любой  пользователь может заменить ее собственной программой. Это особенно критично для программ, имеющих атрибут SUID,  так как пользователь root имеет  права на доступ ко всем файлам системы. (Некоторые системы UNIX  обнуляют  бит   SUID  исполнительного идентификатора  при  модификации файла с тем,  чтобы  уменьшить риск появления бреши в системе безопасности.)

Бит  SUID – мощное средство, но обычно  оно используется лишь в некоторых системных программах, таких как passwd. Рассмотрим теперь обычный файл.

$ ls -l /bin/who

–rwxrwxr–x 1 root              6348 Mar  29   1983 /bin/who

$

Файл who доступен для исполнения всем,  а для записи – владельцу root  и группе владельца. Под «исполнением» здесь понимается следующее: при вводе команды

$ who

оболочка просматривает ряд  каталогов, в том числе  и /bin, в поисках файла who. Если  она находит такой файл, и если  файл имеет разрешение на выполнение, оболочка делает запрос на его выполнение к ядру. Ядро проверяет права доступа и, если  они позволяют, запускает программу. Обратите внимание, что программа – это файл, имеющий раз решение на выполнение. В следующей главе мы рассмотрим програм-

1        Идея атрибута set-uid принадлежит Деннису Ритчи (Dennis Ritchie).

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

Права доступа на  каталоги действуют немного  иначе, хотя основная идея  та же.

$ ls -ld .

drwxrwxr–x 3 you                  80 Sep 27 06:11  .

$

Команда ls с параметром –d выводит сведения о самом  каталоге, а не о его содержимом, а d в начале строки подтверждает, что  «.» действительно является каталогом. Поле r означает, что каталог доступен для  чтения, и его содержимое может быть  просмотрено с помощью команды ls (или, при  желании, od). Наличие w говорит о том,  что возможно создание и удаление файлов в этом  каталоге, поскольку эти действия требуют записи в файл каталога.

На самом  деле вы не можете записывать данные прямо в файл каталога – это запрещено даже суперпользователю.

$ who  >.                        Попытка перезаписать «.»

.: cannot  create        Невозможно

$

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

Разрешение на удаление файла не связано с самим файлом. При  наличии права на запись в каталог можно удалить файлы даже в том случае, если они защищены от записи. Команда rm запрашивает подтверждение перед  тем,  как  удалить защищенный файл, –  это  один  из  тех  редких случаев, когда UNIX  просит пользователя подтвердить его намерения. (Флаг –f позволяет команде rm удалять файлы без лишних вопросов.)

Поле  x в строке прав  доступа к каталогу разрешает не исполнение, а поиск. Разрешение на исполнение для каталога означает, что в нем может  быть выполнен поиск файла. Таким образом, можно создать каталог с правами ––x для остальных пользователей, что позволит им полу чить  доступ к тем файлам, которые им известны, но не даст выполнить команду ls для просмотра всего содержимого каталога. Аналогично, в каталоге с правами доступа r— пользователи могут  просматривать его содержимое, но не могут  с ним работать. В некоторых конфигурациях это свойство используется для  отключения каталога /usr/games в рабочее время.

Команда chmod  (change mode – изменить режим) изменяет права доступа к файлу.

$ chmod  права5доступа имена5файлов

Правда, синтаксис прав5доступа несколько неуклюжий.  Существуют два  способа  описания: в восьмеричном и в символьном виде. Восьмеричные значения легче  в использовании, хотя иногда бывает удобно символьное представление, поскольку оно позволяет описать относи тельные изменения прав. Было бы удобно написать

$ chmod  rw-rw-rw junk                     Этот способ не работает!

вместо

$ chmod  666 junk

но так нельзя. Восьмеричные значения образуются путем суммирования 4 для  чтения, 2 для записи и 1 для  исполнения. Тремя цифрами, как в ls,  обозначаются разрешения для владельца, группы и остальных. Значения символьных кодов  объяснить труднее, исчерпывающее описание имеется на странице руководства chmod(1). Для  наших целей достаточно отметить, что знак + включает право доступа, а знак – его выключает. Например

$ chmod  +x command

позволяет всем выполнять command, а

$ chmod  -w file

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

$ ls -ld /usr/mary

drwxrwxrwx  5 mary              704 Sep 25 10:18  /usr/mary

$ chmod  444 /usr/mary

chmod: can’t  change /usr/mary

$

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

$ cd

$ date >temp

$ chmod  -w .             Запретить запись в каталог

$ ls -ld .

dr–xr–xr–x  3 you                  80 Sep 27 11:48  .

$ rm temp

rm:  temp not  removed          Невозможно удалить файл

$ chmod  775 .            Восстановить права доступа

$ ls -ld .

drwxrwxr–x 3 you                  80 Sep 27 11:48  .

$ rm temp

$                                               Запись в каталог разрешена

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

Упражнение 2.5.  Поэкспериментируйте с chmod.  Попробуйте различные значения, такие как 0 и 1. Будьте осторожны и не повредите свой регистрационный каталог! ~

Источник: Керниган Б., Пайк Р., UNIX. Программное окружение. – Пер. с англ. – СПб: Символ-Плюс, 2003. – 416 с., ил.

По теме:

  • Комментарии