Биты файлового режима находятся в inode (в поле i_mode) файла, а значение по умолчанию для вновь создаваемых файлов определяется значением параметра umask пользователя, причем этот режим может быть изменен владельцем файла с помощью команды chmod(1) (владелец файла может быть изменен командой chown(1)). Там где этого достаточно, безопасность файловой системы в Solaris можно и сегодня поддерживать указанным способом. Однако для систем, требующих большей гибкости и контроля в управлении безопасностью, существуют ACL, которые были впервые введены в Solaris 2.5.1.

ACL позволяет владельцу файла управлять правами на файлы и каталоги в UFS (файловая система по умолчанию в Solaris) для отдельных пользователей и групп. Кроме того, владелец файла может определять набор прав по умолчанию в каталоге, так что все файлы, создаваемые в этом каталоге, получают одинаковый набор ACL. Поддержка ACL существует сегодня в Solaris для следующих типов файловых систем: UFS, NFS (версии 2 и 3), CacheFS и LOFS.

Другие типы файловых систем в Solaris ничего не знают об ACL, и следовательно, не могут осуществлять защиту в соответствии с ACL файла. Кроме того, ACL могут применяться только к каталогам, нормальным файлам, FIFOs и символическим ссылкам (symbolic links).

3.3.2 Формат ACL

Формат для файлового ACL состоит из двух или трех колонок, разделенных двоеточием:

entry_type:[uid|gid]:perms

Первая колонка, entry_type, определяет ACL для пользователя, группы, других или маску (ACL mask). Вторая колонка - это (возможно) пользовательский ID (UID) или имя пользователя, или групповой ID (GID) или имя группы. Для типов other или mask, эта колонка неприменима и потому не требуется. Третья колонка предназначена для файловых разрешений. Файловые разрешения принимают форму либо обычных rwx (read/write/execute), либо числовую форму в восьмеричной системе (например, 7 для rwx, 4 для r--, 6 для rw-, и т.д.), что полностью эквивалентно формату в chmod(1). Внутреннее представление в виде структуры данных выглядит так (из /usr/include/sys/acl.h):

typedef struct acl {

int a_type; /* тип записи */

uid_t a_id; /* UID | GID */

o_mode_t a_perm; /* разрешения */

} aclent_t;

Каждое поле в указанной структуре соответствует частичному полю ACL, описанным выше.

Когда идентификатор пользователя (или UID) отсутствует, и поле идентификатора группы (или GID) пусто, то применяются традиционные файловые права Solaris (это будет показано в примере ниже). Пользователи устанавливают, модифицируют и удаляют ACL с помощью команды setfacl(1), и проверяют файловые ACL с помощью команды getfacl(1).

3.3.3 Примеры работы с ACL

Короткий пример ниже демонстрирует использование файловых ACL.

1 sunsys> ls -l file1

2 -rwxr-xr-- 1 joe staff 130 May 25 22:13 file1

3 sunsys> chmod 000 file1

4 sunsys> ls -l file1

5 ---------- 1 joe staff 130 May 25 22:13 file1

6 sunsys> setfacl -s user::rw-,group::r--,other:r-- file1

7 sunsys> ls -l file1

8 -rw-r--r-- 1 joe staff 130 May 25 22:13 file1

9 sunsys> getfacl file1

10 # file: file1

11 # owner: joe

12 # group: staff

13 user::rw-

14 group::r-- #effective:r--

15 mask:r--

16 other:r--

17 sunsys> setfacl -m user:moe:rw- file1

18 sunsys> ls -l file1

19 -rw-r--r--+ 1 joe staff 130 May 25 22:13 file1

20 sunsys> getfacl file1

21 # file: file1

22 # owner: joe

23 # group: staff

24 user::rw-

25 user:moe:rw- #effective:r--

26 group::r-- #effective:r--

27 mask:r--

28 other:r—

Строка 6 демонстрирует команду setfacl(1) с опцией -s, которая означает установку ACL. Команда setfacl(1) в строке 6 не определяет специальных прав для конретных пользователей или групп. Это в основном эквивалентно исполнению команды chmod 644 над тем же файлом.

С помощью команды getfacl(1) (строка 9) отображаются файловые права в формате ACL. Фактически в этот момент для этого файла ACL не определен. Ядро Solaris отслеживает установку ACL, и для простых случаев, когда команда setfacl(1) просто устанавливает традиционные файловые права для владельца, группы-владельца и остальных, реальный ACL для файла не создается. Ядро устанавливает права, определенные командой setfacl(1) в соответствующем поле в inode.

В строке 17 устанавливаются права на чтение и запись для пользователя Moe, используя опцию –m (modify, изменить) с командой setfacl(1). Теперь при запуске команды getfacl(1) (строка 20), мы видим добавление ACE для пользователя Moe в ACL.

Есть несколько важных моментов по поводу поведения ACL и правил старшинства. Этот пример показывает ACL с маской “r--”. Маска ACL определяет максимальные права, выделенные всем, кроме владельца файла; в данном примере все, кроме владельца файла имеют права только на чтение. Однако, в ACL определены права на чтение и запись для пользователя Moe. Так что же случится, если пользователь Moe попытается записать в файл - что окажется главнее - его специальные права или маска ACL? Ответ заключается в том, что “победит” маска ACL. Вот еще один короткий пример:

1 sunsys> getfacl file1

2 # file: file1

3 # owner: joe

4 # group: staff

5 user::rw-

6 user:moe:rw- #effective:r--

7 group::r-- #effective:r--

8 mask:r--

9 other:r--

10 sunsys> su moe

11 Password:

12 $ id

13 uid=2001(moe) gid=22(stooges)

14 $ echo "write test" >> file1

15 file1: cannot create

16 $ exit

17 sunsys> setfacl -m m:rw- file1

18 sunsys> getfacl file1

19 # file: file1

20 # owner: joe

21 # group: staff

22 user::rw-

23 user:moe:rw- #effective:rw-

24 group::r-- #effective:r--

25 mask:rw-

26 other:r--

27 sunsys> su moe

28 Password:

29 $ echo "write test" >> file1

30 $ exit

31 sunsys>

Здесь не были рассмотрены, конечно, все варианты установки прав ACL. Более подробная информация содержится в страницах руководства setfacl(1) и getfacl(1), а также в документации Solaris. Для программных вызовов ACL существуют acl(2) и facl(2), а также библиотечные функции aclcheck(3) и aclsort(3).

3.4 NFS и ACL

Полная поддержка ACL для NFS требует двух составляющих: во-первых, механизма, который бы позволял принимать все решения относительно прав доступа так, как этого требует ACL; во-вторых, расширений протокола NFS для использования ACL на смонтированных удаленных файловых системах.

Протокол NFS производит кэширование на стороне клиента для увеличения эффективности. Во второй версии протокола решения, для кого должен предоставляется доступ на чтение локальных данных из кэша, осуществляется на стороне клиента. Принятие этих решений основывается на предположении, что файловых битов режима доступа и идентификаторов владельца и группы-владельца достаточно для принятия такого решения. Это предположение очевидно ошибочно, если на сервере используется расширенная схема разрешений, такая как POSIX ACL.