GLIBC предоставляет дополнительную функцию, которая работает подобно access(), но проверяет в соответствии с эффективными UID, GID и набором групп:

#include /* CLIBC */

int euidaccess(const char *path, int amode);

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

В противном случае euidaccess() сравнивает значения владельца и группы файла со значениями эффективных UID и GID и набора групп, используя соответствующие биты прав доступа. Этот тест основан на сведениях о файле от stat().

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

11.5. Установка дополнительных битов доступа для каталогов

На современных системах setgid и «липкий» биты имеют особое значение при применении к каталогам.

11.5.1. Группа по умолчанию для новых файлов и каталогов

В оригинальной системе Unix, когда open() или creat() создавали новый файл, он получал эффективные UID и GID создавшего их процесса.

V7, BSD вплоть до BSD 4.1 и System V вплоть до Release 3 все трактовали каталоги как файлы. Однако, с добавлением дополнительного набора групп в BSD 4.2 способ создания новых каталогов изменился: новые каталоги наследовали группу родительского каталога. Более того, новые файлы также наследовали ID группы родительского каталога, а не эффективный GID создающего процесса.

Идея, лежащая в основе множества групп и каталогов, которые работают таким способом, была в усилении группового взаимодействия. У каждого проекта организации, использующего систему, была бы отдельная назначенная ему группа. Для каждой такой группы в группе этого проекта был бы каталог верхнего уровня, и все файлы проекта имели бы доступ на чтение и запись (а при необходимости и на исполнение). Вдобавок, новые файлы автоматически получают группу родительского каталога. Состоя одновременно в нескольких группах (наборе групп), пользователь мог бы как угодно перемещаться между проектами с помощью простой команды cd, а все файлы и каталоги сохраняли бы свою надлежащую группу.

Что происходит на современных системах? Ну, это еще один из немногих случаев, когда можно поймать двух зайцев. SunOS 4.0 придумал механизм, который был включен в System V Release 4; сегодня он используется по крайней мере в Solaris и GNU/Linux. Эти системы придают биту setgid родительского каталога нового файла или каталога следующее значение:

Бит setgid родительского каталога сброшен

Новые файлы и каталоги получают эффективный GID создающего процесса.

Бит setgid родительского каталога установлен

Новые файлы и каталоги получают GID родительского каталога. Новые каталоги наследуют также установленный бит setgid.

(До SunOS 4.0 бит setgid для каталогов не имел определенного значения.) Следующий сеанс показывает бит setgid в действии:

$ cd /tmp /* Перейти в /tmp */

$ ls -ld . /* Проверить его права доступа */

drwxrwxrwt 8 root root 4096 Oct 16 17:40 .

$ id /* Отметить текущие группы */

uid=2076(arnold) gid=42(devel) groups=19(floppy),42(devel),2076(arnold)

$ mkdir d1 ; ls -ld d1 /* Создать новый каталог */

drwxr-xr-x 2 arnold devel 4096 Oct 16 17:40 d1 /* Эффективный ID группы

                                                  наследуется */

$ chgrp arnold d1 /* Сменить группу */

$ chmod g+s d1 /* Добавить бит setgid */

$ ls -ld d1 /* Проверить изменение */

drwxr-sr-x 2 arnold arnold 4096 Oct 16 17:40 d1

$ cd d1 /* Перейти в него */

$ echo this should have group arnold on it > f1 /* создать новый файл */

$ ls -l f1 /* Проверить права доступа */

-rw-r--r-- 1 arnold arnold 36 Oct 16 17:41 f1

 /* Унаследовано от родителя */

$ mkdir d2 /* Создать каталог */

$ ls -ld d2 /* Проверить права доступа */