by Dru Lavigne
09/22/2005
Original

Перевод: Сгибнев Михаил

Пять лет назад (неужели на самом деле прошло столько времени?) я написала цикл статей Основы прав доступа в Unix. С тех пор в FreeBSD была реализована такая концепция, как ACL (Access Control Lists).

ACL пришли в BSD как часть проекта TrustedBSD. Как следует из названия, списки доступа предлагают более тонкое управление правами в системе.

Почему я должен захотеть использовать ACL?

Хотя ACL не изменяют внутренние разрешения Unix ((r)ead, (w)rite и e(x)ecute), они действительно позволяют лучше управлять доступом. Рассмотрим такой пример, когда пользователь создает тестовый файл в каталоге /tmp:

% touch /tmp/test
% ls -l /tmp/test
-rw-r--r--  1 dru  dru  0 Jul 26 15:43 /tmp/test

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

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

Теперь предположим, что необходимо дать права на запись в этот файл пользователям rob и toby. В том виде, в какой сейчас установлены права доступа, они могут открыть этот файл, но не смогут сохранить изменения, поскольку они явно не пользователь dru, обладающего такими правами, а относятся к категории other.

До существования ACL типичное решение этой проблемы заключалось бы в изменении членства в группе. Например, я могла бы попросить системного администратора добавить пользователей rob и toby в группу dru и использовать команду chmod для того, чтобы разрешить запиь в этот файл для группы dru, так как это лучше, чем позволять писать в файл кому ни попадя.

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

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

Все начинает казаться немного сложным? Все это уже позади, так как есть ACL. Без необходимости просить администратора или использовать chgrp, dru может легко дать права на запись в некоторые файлы только rob, а некоторым только toby.

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

Подготовка системы

Если вы используете FreeBSD 5.1 или более позднюю, поддержка ACL уже интегрирована в ядро и файловую систему UFS2. Для более ранних версий FreeBSD, смотрите инструкцию по компилированию поддержки ACL в FreeBSD Дэниела Харриса.

Вам просто необходимо указать, с какими файловыми системами вы будете использовать ACL:

# df
Filesystem  1K-blocks    Used   Avail Capacity  Mounted on
/dev/ad0s1a    253678   35764  197620    15%    /
devfs               1       1       0   100%    /dev
/dev/ad0s1e    253678      22  233362     0%    /tmp
/dev/ad0s1f   8077406 3045460 4385754    41%    /usr
/dev/ad0s1d    253678   21048  212336     9%    /var

В моей системе я хочу сконфигурировать ACLs только для пользователей и только для каталога /usr

Руководство пользователя FreeBSD объясняет преимущества использования команды tunefs для активирования ACL, но ее использование требует перехода в однопользовательский режим и отмонтирования всех файловых систем. Выберите подходящее время, когда вы будете уверены, что никого нет в системе и выполните следующую команду:

# shutdown now
Enter full pathname of shell or RETURN for /bin/sh: 

# /sbin/umount /usr
# /sbin/tunefs -a enable /dev/ad0s1f
tunefs: ACLs set
# /sbin/mount /usr

Используйте свое имя устройства, которое вы посмотрели в выводе команды df.

Теперь давайте проверим, как это работает:

# /sbin/mount
/dev/ad0s1a on / (ufs, local)
devfs on /dev (devfs, local)
/dev/ad0s1e on /tmp (ufs, local, soft-updates)
/dev/ad0s1f on /usr (ufs, local, soft-updates, acls)
/dev/ad0s1d on /var (ufs, local, soft-updates)

И вернемся в многопользовательский режим:

# exit

Теперь наша система готова к использованию ACL.

Установка инструментария

Если вы попробуете поискать в Google ключевые слова "FreeBSD acl", то вы найдете несколько статей и how-to. В каждой из них будет насколько примеров использования утилит командной строки getfacl и setfacl, как, например, в замечательной статье Грега Кзаплински Работа с ACL с FreeBSD 5.x.

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

eiciel обеспечивает интуитивно понятный графический интерфейс пользователя и доступен из системы портов FreeBSD. Также он работает на Linux и является частью файлового менеджера Nautilus, который, между прочим, добавляет список свойств к файлам, разрешая пользователю легко устанавливать и управлять правами доступа к файлам, иконками, и утилитой Open With.

Вы можете легко установить эту утилиту командой:

# pkg_add -r eiciel

Работа с утилитой

Есть два способа запуска утилиты управления ACL. На Рис.1 представлен первый путь - доступ через nautilus. Пользователь dru имеет три файла в своем домашнем каталоге, называемые test, file1 и myfile. На Рис.2 показано, что случится при щелчке правой кнопкой мыши на файле test и выборе Properties (Свойства).


Рис.1 Nautilus


Рис.2 Меню Properties

После установки eiciel в Nautilus будет добавлена вкладка Access Control List. На этой вкладке вы можете увидеть, что в настоящий момент права доступа к этому файлу выглядят так:

% ls -l test
-rw-r--r--  1 dru  dru  0 Jul 27 09:09 test

Другой метод заключается в непосредственном запуске eiciel, что показано на Рис.3. Нажмите на кнопку Open для выбора файла test (Рис.4), после чего откроется окно ACL (Рис.5).


Рис.3 Запуск eiciel


Рис.4 Открытие файла в eiciel


Рис.5 Редактирование ACL в eiciel

Я выбрала работу через Nautilus, поскольку в этом случае доступна вкладка Permissions (Разрешения), позволяющая просматривать и изменять:

• владельца файла
• группу файла (аналог chgrp)
• специальные флаги, такие как SUID, SGID и sticky bit
• разрешения в текстовом представлении (как ls -l)
• разрешения в числовом представлении (644)

Работа с масками ACL

Обратим взор на Рис.2. Здесь вы можете просмотреть пользователей и группы, существующие в системе. Дважды щелкните на пользователе rob, в результате чего в верхней чати вкладки добавится два обьекта, что показано на Рис.6


Рис.6 Добавление пользователя в ACL

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

Учтите, что записи за rob и mask имеют разрешения rwx, хотя это даже больше, чем имеет dru, владелец файла. Что же произошло? Двойным щелчком на rob я добавила ACL, который я проверяю полным листингом домашнего каталога:

% ls -l
drwx------  2 dru  dru   512 Jul 26 10:35 Desktop
-rw-r--r--  1 dru  dru     0 Jul 27  9:22 file1
-rw-r--r--  1 dru  dru     0 Jul 27  9:22 myfile
-rw-r--r--+ 1 dru  dru     0 Jul 27 10:03 test

Вы видите + в конце колонки прав доступа? Это признак того, что на файле установлен ACL. Просмотрим его с помощью getfacl:

% getfacl test
#file:test
#owner:1001
#group:1001
user::rw-
user:rob:rwx
group::r--
mask::rwx
other::r--

Этот вывод аналогичен тому, что мы видим на Рис.6, только в текстовом представлении. Почему rob получил права rwx и что за запись mask? Смысл маски заключается в задании прав по умолчанию. Для того, чтобы вы поняли, что это значит, сделаем следущее:

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

Что случится, если вы измените маску? Верните Робу права rwx, но снимите флаг execute с маски. Как только вы сделаете это, флаг execute в строке Роба будет отмечен красным восклицательным знаком. Утилита также отобразит сообщение, что восклицательный знак указывает на "an ineffective permission".

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

% getfacl test
#file:test
#owner:1001
#group:1001
user::rw-
user:rob:rwx# effective: rw-
group::r--
mask::rw-
other::r--

Работа с ACL для доступа к каталогам

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

Каталоги являются более сложными образованиями, поэтому добавляются еще три типа ACL:

• access ACL, определяющий доступ непосредственно к каталогу
• default directory ACL, указывающий права доступа по умолчанию ко всем создаваемым подкаталогам
• default access ACL, определяющий права доступа ко всем файлам, создаваемых в этом каталоге. Обратите внимание на то, что если default directory ACL не установлен, подкаталоги также следуют этому листу. Если default directory ACL установлен, то он перекрывает этот лист.

В настоящее время реализация ACL в FreeBSD включает только первые два пункта. Стоит дважды проверить наличие effective permissions на любых файлах, которые вы создаете в каталогах, содержащих ACLs.

Для того, чтобы увидеть, как это работает, создайте каталог folder.

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

Посмотрите на свойства ACL для folder (Рис.7) Асе очень похоже на свойства файла, за исключением кнопки Default ACL и флага Default:


Рис.7 Свойства ACL для нового каталога

User, Group и Other описывают непосредственный доступ к каталогу и поэтому представляют первый тип ACL , или access ACL.


Рис.8 Добавляем default ACL

Щелкните по кнопке Default ACL. На Рис.8 показано четыре дополнительные строки, они описывают второй тип ACL, или default directory ACL, который действует только для подкаталогов. Для проверки создайте подкаталог и файл:

% getfacl folder
#file:folder
#owner:1001
#group:1001
user::rwx
group::r-x
other::r-x

% mkdir folder/subfolder
% touch folder/testfile
% ls -l folder
drwxr-xr-x+ 2 dru  dru  512 Jul 27 12:23 subfolder
-rw-r--r--+ 1 dru  dru    0 Jul 27 12:23 testfile

Обратите внимание, что subfolder, в отличие от файла, унаследовала права доступа.

Добавление пользователей в ACL каталога

Если я вернусь обратно, к свойствам папки, и добавлю Роба, будет ли он иметь доступ на запись в folder/subfolder и folder/testfile? Нет. Все изменения коснутся только подкаталогов и файлов, созданных после установки ACL.

При добавлении Роба, так же есть выбор: если просто два раза щелкнуть на имени пользователя, то rob получит доступ к каталогу. Другими словами, я изменяю первый тип ACL. Однако, если я сначала активирую поле Default и затем дважды щелкаю на rob, то я изменяю второй тип доступа, или разрешения rob на подкаталоги, которые я создаю. Я могу добавить Роба обоими способами. Если учетная запись помечена знаком D, то права доступа включают подкаталоги; если нет, то доступ указан только для этого каталога.

Для демонстрации написанного добавим оба варианта для пользователя rob, опять дав ему права rwx. Для того, чтобы увидеть требуемый эффект, создадим еще один подкаталог и файл:

% mkdir folder/subfolder2
% touch folder/testfile2

На Рис.9 показаны установленные ACL. Как и ожидалось, default directory ACL помечен символом D, rob со знаком D унаследовал права rwx от родительского каталога. При этом, access ACL, представленный учетной записью Рода без символа D, показывает "ineffective permission". Другими словами, поскольку Робу был предоставлен доступ только к каталогу верхнего уровня, он не имеет разрешений на подкаталоги, поэтом Роб имеет такие же права доступа к подкаталогам, как и любой другой пользователь. Однако, вы можете изменить маску, добавив туда атрибут для записи. Если вы действительно изменяете маску, проверьте, что другой пользователь не получил прав на запись.


Рис.9 Effective ACLs

Как только вы поняли смысл установки прав доступа для folder/subfolder2, обратите внимание на свойства testfile2, отображенные на Рис.10 Здесь нет ни одного значка, отмеченного символом D. Это связано с тем, что файлы не наследуют default directory ACL. Поскольку в настоящий момент нет поддержки default access ACL, rob не наследует никаких прав доступа вообще от каталога или от подкаталога и имеет теже права доступа как и любой другой пользователь. Снова решение заключается в смене маски и проверке, не оттяпал ли кто из пользователей больше прав, чем ему положено.


Рис.10 Файлы и default directory ACL

Резервное копирование ACL

Вы должны запомнить, что большинство программ резервного копирования будут корректно сохранять и восстанавливать файлы с установленными на них ACL, но сами ACL будут потеряны. Хорошим решением этой проблемы будет установка /usr/ports/archivers/star из системы портов. Если вы когда либо работали с tar, то обучение работе с этой программой не займет у вас много времени, поскольку потребуется лишь выучить несколько флагов, позволяющих сохранять атрибуты ACL.

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

# mkdir -p /usr/backups/dru
# chmod dru:dru /usr/backups/dru
# exit

Теперь dru может сделать архив файлов, содержащих ACL:

% whoami
dru
% cd
% star -cv -Hexustar -acl -f /usr/backups/dru/home.tgz .

Для проверки, восстановим данные из архива:

% mkdir ~/tmp
% cd ~/tmp
% star -xv -Hexustar -acl -f home.tgz

Обратите внимание на то, что если вы будете распаковывать архив на системе, не поддерживающей ACL, то star выдаст предупреждение, но архив будет распакован.

Заключение

Большинство пользователей или никогда не слышали об ACL или считают их слишком сложными в использовании. Потратьте полчаса времени, покажите им как пользоваться eiciel и star и они просто жизни себе не смогут представить без ACL.