Текст книги "Linux программирование в примерах"
Автор книги: Арнольд Роббинс
Жанры:
Программирование
,сообщить о нарушении
Текущая страница: 34 (всего у книги 55 страниц)
euidaccess() (GLIBC)GLIBC предоставляет дополнительную функцию, которая работает подобно access(), но проверяет в соответствии с эффективными UID, GID и набором групп:
#include
int euidaccess(const char *path, int amode);
Аргументы и возвращаемое значение имеют тот же смысл, как для access(). Когда равны эффективный и действительный UID и эффективный и действительный GID, euidaccess() вызывает для осуществления теста access(). Это имеет то преимущество, что ядро может проверить файловую систему только для чтения или другие условия, которые не отражаются в правах доступа и владении файлами.
В противном случае euidaccess() сравнивает значения владельца и группы файла со значениями эффективных UID и GID и набора групп, используя соответствующие биты прав доступа. Этот тест основан на сведениях о файле от stat().
Если вы пишете переносимую программу, но предпочитаете использовать этот интерфейс, достаточно просто извлечь исходный файл из архива GLIBC и приспособить его для общего использования.
11.5. Установка дополнительных битов доступа для каталоговНа современных системах setgid и «липкий» биты имеют особое значение при применении к каталогам.
В оригинальной системе 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 /* Проверить права доступа */
drwxr-sr-x 2 arnold arnold 4096 Oct 16 17:51 d2
/* Группа и setgid унаследованы */
Файловые системы ext2 и ext3 для GNU/Linux работают указанным способом. Вдобавок они поддерживают специальные опции монтирования grpid и bsdgroups, которые делают «использование группы родительского каталога» семантикой по умолчанию. (Два имени означают одно и то же.) Другими словами, когда используются эти опции монтирования, в родительских каталогах не нужно устанавливать свои биты seigid.
Противоположными опциями монтирования являются nogrpid и sysvgroups. Это поведение по умолчанию; однако, бит setgid. если он есть, все равно учитывается. (Здесь также оба имени означают одно и то же.)
POSIX устанавливает, что новые файлы и каталоги наследуют либо эффективный GID создающего процесса, либо группу родительского каталога. Однако, реализации должны предусмотреть способ заставить новые каталоги наследовать группу родительского каталога. Более того, стандарт рекомендует, чтобы приложения не полагались на то или иное поведение, но в случаях, когда это имеет значение, использовали chown() для принудительного назначения желательного GID для группы нового файла или каталога.
«Шерман, установите машину времени для 1976 г.»
– М-р Пибоди (Mr. Peabody) -
«Липкий» бит ведет начало от версий Unix для PDP-11, он использовался с обычными исполняемыми файлами[119]119
На ум приходят образы счастливых юных программ их лица и руки, запачканные шоколадом – Примеч. автора.
[Закрыть]. Этот бит использовался с программами, которые предназначались для интенсивного использования, такими, как оболочка и редактор. Когда у программы был установлен этот бит, ядро хранило копию исполняемого кода программы на устройстве подкачки, из которого ее можно было быстро загрузить в память для повторного использования. (Загрузка из файловой системы занимает больше времени образ на устройстве подкачки хранился в смежных дисковых блоках, тогда как образ в файловой системе мог быть разбросан по всему диску). Исполняемые образы были «приклеены» к устройству подкачки, отсюда и название.
Таким образом, даже если программа в настоящее время не использовалась, предполагалось, что она вскоре могла быть использована другим пользователем, поэтому она могла быть быстро загружена.
В современных системах значительно более быстрые дисковое оборудование и память, чем в давнишней PDP-11. Они используют также методику, называемую подкачка по требованию, для загрузки в память лишь тех частей исполняемой программы, которые выполняются. Таким образом, сегодня «липкий» бит обычных исполняемых файлов не служит никаким целям и на самом деле ни на что не влияет.
Однако, в разделе 1.1.2 «Каталоги и имена файлов» мы упомянули, что «липкий» бит в каталоге, запись в который в других отношениях разрешена, предотвращает удаление файлов из этого каталога и их переименование любым пользователем, кроме владельца файла или root. Вот пример:
$ ls -ld /tmp /* Показать права доступа к /tmp */
drwxrwxrwt 19 root root 4096 Oct 20 14:04 /tmp
$ cd /tmp /* Перейти туда */
$ echo this is my file > arnolds-file /* Создать файл */
$ ls -l arnolds-file /* Показать его права доступа */
-rw-r–r– 1 arnold devel 16 Oct 20 14:14 arnolds-file
$ su – miriam /* Смена пользователя */
Password:
$ cd /tmp /* Перейти в /tmp */
$ rm arnolds-file /* Попытка удаления файла */
rm: remove write-protected regular file 'arnolds-file'? y
/* rm предупреждает */
rm: cannot remove 'arnolds-file': Operation not permitted
/* Ядро запрещает удаление */
Основным назначением этой особенности является как раз использование в таких каталогах, как /tmp, куда хотят помещать свои файлы множество пользователей. С одной стороны, каталог должен иметь права записи для всех, чтобы каждый мог создавать там свои файлы. С другой стороны, раз запись разрешена для всех, любой пользователь может удалять файлы всех остальных пользователей! «Липкий» бит каталога красиво решает эту проблему. Для добавления к файлу или каталогу «липкого» бита используйте 'chmod +t':
$ mkdir mytmp /* Создать каталог */
$ chmod a+wxt mytmp /* Добавить права записи для всех и «липкий» бит */
$ ls -ld mytmp /* Проверить результат */
drwxrwxrwt 2 arnold devel 4096 Oct 20 14:23 mytmp
В заключение, обратите внимание, что владелец каталога также может удалить файлы, даже если они не принадлежат ему.
11.6. Установка действительных и эффективных IDВсе становится интереснее, когда процессу приходится менять значения UID и GID. Установка набора групп проста. Изменение значений действительных и эффективных UID и GID сложнее.
Функция setgroups() устанавливает новый набор групп:
#include
#include
#include
int setgroups(size_t size, const gid_t *list);
Параметр size указывает, сколько элементов в массиве list. Возвращаемое значение равно 0, если все было нормально, и -1 с установленным errno в противном случае.
В отличие от функций для манипулирования значениями действительных и эффективных UID и GID, эту функцию может вызвать лишь процесс, действующий как root. Это один пример того, что POSIX называет привилегированной операцией; сама она как таковая не стандартизуется POSIX.
setgroups() используется любой программой, которая осуществляет регистрацию в системе, такой как /bin/login для регистрации в консоли и /bin/sshd для удаленной регистрации с помощью ssh.
Работа с двумя различными ID пользователей представляет для программиста приложения проблему. Могут быть вещи, которые программе нужно сделать, работая с эффективным UID, а другие вещи – работая с действительным UID.
Например, до того, как в системах Unix появилось управление заданиями, многие программы предоставляли переходы в оболочку, т.е. способ запуска команды или интерактивной оболочки из текущей программы. Хорошим примером этого является редактор ed: набор командной строки, начинающейся с '!', запускает оставшуюся часть строки в качестве команды оболочки. Набрав '!sh', вы получаете интерактивную оболочку. (Это работает до сих пор – попробуйте!) Предположим, описанная ранее гипотетическая игровая программа также предоставляет переход в оболочку: она должна быть запущена от имени действительного пользователя, а не эффективного. В противном случае, редактирование файла счета или многие гораздо худшие вещи становятся для игрока тривиальной задачей!
Таким образом, имеется явная потребность в возможности замены эффективного UID действительным UID. Более того, полезна возможность обратного переключения эффективного UID на первоначальный. (В этом причина необходимости наличия сохраненного set-user ID; появляется возможность восстановления первоначальных привилегий, которые были у процесса при его запуске.)
Как и для множества Unix API, различные системы решили проблему разными способами, иногда с использованием одного и того же API, но с другой семантикой, а иногда введением другого API. Погружение в исторические подробности годится лишь для создания головной боли, поэтому мы не будем с этим беспокоиться. Вместо этого мы рассмотрим, что предоставляет POSIX и как работает каждый API. Более того, наше обсуждение фокусируется на значениях действительных и эффективных UID; значения GID работают аналогичным образом, поэтому мы не будем хлопотать с повторением подробностей для этих системных вызовов. Функции следующие:
#include
#include
int seteuid(uid_t euid); /* Установка эффективного ID */
int setegid(gid_t egid);
int setuid(uid_t uid);
/* Установка эффективного ID, root устанавливает все */
int setgid(gid_t gid);
int setreuid(uid_t ruid, uid_t euid);
/* Совместимость с BSD, устанавливаются оба */
int setregid(gid_t rgid, gid_t egid);
Есть три набора функций. Первые два были созданы POSIX:
int seteuid(uid_t euid)
Эта функция устанавливает лишь эффективный UID. Обычный пользователь (не root) может установить в качестве ID лишь в значения действительного, эффективного или сохраненного set-user ID. Приложения, которые будут переключать эффективный UID. должны использовать исключительно эту функцию.
Процесс с эффективным UID, равным нулю, может установить в качестве эффективного UID любое значение. Поскольку в качестве значения эффективного UID можно установить также сохраненный set-user ID, процесс может восстановить свои привилегии root с помощью другого вызова seteuid().
int setegid(gid_t egid)
Эта функция делает для эффективного ID группы то, что seteuid() делает для эффективного ID пользователя.
Следующий набор функций предлагает первоначальный API Unix для изменения действительных и эффективных UID и GID. В модели POSIX эти функции являются тем. что должна использовать программа с setuid-root для постоянного изменения действительного или эффективного UID:
int setuid(uid_t uid)
Для обычного пользователя эта функция также устанавливает лишь эффективный UID. Как и для seteuid(), значением эффективного UID может быть любое из текущих значений действительного, эффективного иди сохраненного set-user ID. Изменение не постоянно; эффективный UID может быть изменен последующим вызовом на другое значение (из того же исходного набора).
Однако, для root эта функция устанавливает в данное значение все три значения для действительного, эффективного и сохраненного set-user ID. Более того, изменение постоянно; прежнее ID нельзя восстановить. (Это имеет смысл: раз изменился сохраненный set-user ID, нет другого ID для восстановления.)
int setgid(gid_t gid)
Эта функция делает для эффективного ID группы то же, что setuid() делает для эффективного ID пользователя. Используется то же разграничение между обычными пользователями и root.
ЗАМЕЧАНИЕ. Возможность изменения ID группы зависит от эффективного ID пользователя. Эффективный GID, равный 0, не имеет особых привилегий.
Наконец, POSIX представляет для исторической совместимости две функции из BSD 4.2. В новом коде их лучше не использовать. Однако, поскольку вы, вероятно, увидите использующий эти функции старый код, мы их здесь опишем.
int setreuid(uid_t ruid, uid_t euid)
Устанавливает данные значения в качестве действительного и эффективного UID. Значение -1 для ruid или euid оставляет соответствующие ID без изменения. (Это похоже на chown(); см. раздел 5.5.1 «Смена владельца файла: chown(), fchown() и lchown()».)
root может устанавливать в качестве действительного и эффективного ID любое значение. В соответствии с POSIX пользователи, не являющиеся root, могут изменять лишь эффективный ID; то, что случится, если обычный пользователь попытается изменить действительный UID, «не определено». Однако, справочная страница GNU/Linux setreuid(2) разъясняет поведение Linux, в качестве действительного UID может быть установлено значение действительного или эффективного UID, а в качестве эффективного UID может быть значение действительного, эффективного или сохраненного set-user ID. (Для других систем см. справочную страницу setreuid(2).)
int setregid(gid_t rgid, gid_t egid)
Делает для действительных и эффективных ID групп то же, что setreuid() делает для действительных и эффективных ID пользователя. Используется то же разграничение между обычными пользователями и root.
Сохраненный set-user ID в модели BSD не существует, поэтому лежащей в основе setreuid() и setregid() идеей было упростить переключение между действительным и эффективным ID:
setreuid(geteuid(), getuid()); /* обмен действительным и эффективным */
Однако, с принятием POSIX модели сохранения set-user ID и функций seteuid() и setegid() функции BSD не следует использовать в новом коде. Даже документация BSD 4.4 помечает эти функции как устаревшие, рекомендуя вместо них seteuid()/setuid() и setegid()/setgid().
Есть важные случаи, в которых действующая как root программа должна безвозвратно изменить все три значения действительного, эффективного и сохраненного set-user ID на ID обычного пользователя. Наиболее очевидным случаем является программа login, которую вы используете (либо непосредственно, либо удаленно) каждый раз при регистрации в системе GNU/Linux или Unix. Имеется иерархия программ, как очерчено на рис. 11.1.
Рис. 11.1. От init через getty через login к shell
Код для login слишком сложен, чтобы показать здесь, поскольку он имеет дело с рядом задач, не имеющих отношения к текущему обсуждению. Но мы можем очертить шаги, которые происходят во время регистрации, следующим образом:
1. init является самым первым процессом. Его PID равен 1. Все другие процессы являются его потомками. Ядро вручную создает процесс 1 во время загрузки и запускает в нем init. Он действует с действительным и эффективным UID, равными нулю, т.е. как root.
2. init читает /etc/inittab, который, помимо прочих вещей, сообщает init о том, на каких устройствах он должен запустить процесс getty. Для каждого такого устройства (такого, как консоль, последовательные терминалы или виртуальные консоли в системе GNU/Linux) init порождает новый процесс. Этот новый процесс использует затем exec() для запуска getty (от «get tty» («получить tty», т.е. терминал)). На многих системах GNU/Linux эта команда называется mingetty. Программа открывает устройство, сбрасывает его состояние и выводит приглашение 'login:'.
3. По получении регистрационного имени getty выполняет login. Программа login ищет имя пользователя в файле паролей, запрашивает пароль и проверяет его. Если пароль подходит, процесс login продолжается.
4. login изменяет домашний каталог пользователя, устанавливает начальное окружение, а затем устанавливает начальный набор открытых файлов. Он закрывает дескрипторы файлов, открывает терминал и использует dup() для копирования дескрипторов файла терминала в 0, 1 и 2. Вот откуда происходят дескрипторы уже открытых файлов стандартного ввода, стандартного вывода и стандартной ошибки.
5. Затем login использует setgroups() для установки дополнительного набора групп, setgid() для установки значений действительного, эффективного и сохраненного set-group ID в соответствующее значение группы пользователя, и наконец, setuid() для установки всех трех значений действительного, эффективного и сохраненного set-user ID в соответствующие значения для регистрирующегося пользователя. Обратите внимание, что вызов setuid() должен быть последним для того, чтобы другие два вызова завершились успешно.
6. Наконец, login вызывает зарегистрированную оболочку пользователя. Оболочки в стиле Борна после этого читают файлы /etc/profile и $HOME/.profile, если они существуют. Затем оболочка выводит приглашение.
Обратите внимание, как один процесс меняет свою сущность от системного процесса до процесса пользователя. Каждый потомок init начинается как копия init. Используя exec(), тот же самый процесс выполняет различные задания. Вызвав setuid() для перехода от root к обычному пользователю, процесс в конечном счете поступает непосредственно для работы пользователя. Когда вы выходите из оболочки (посредством CTRL-D или exit), процесс попросту завершается. Затем init возобновляет цикл, порождая новый getty, который выводит новое приглашение 'login:'.
ЗАМЕЧАНИЕ. Открытые файлы остаются открытыми и доступными для использования, даже после изменения процессом своих UID или GID. Таким образом, программы с setuid должны заранее открыть все нужные файлы, изменить их ID на ID действительного пользователя и продолжить оставшуюся часть работы без дополнительных привилегий
В табл. 11.1 приведена сводка шести стандартных функций для манипулирования значениями UID и GID.
Таблица 11.1. Сводка API для установки действительных и эффективных ID[120]120
E (Effective) эффективный ID, R (Real) действительный ID и S (Saved) сохраненный ID – Примеч. науч. ред.
[Закрыть]
seteuid() | E | Нет | Из R, E, S | Любое |
setegid() | E | Нет | Из R, E, S | Любое |
setuid() | Root: R,E,S Другие: E | Root: да Другие: нет | Из R, E | Любое |
setgid() | Root: R,E,S Другие: E | Root: да Другие: нет | Из R, E | Любое |
setreuid() | E, может установить R | Нет | Из R, E | Любое |
setregid() | E, может установить R | Нет | Из R, E | Любое |
11.7. Работа со всеми тремя ID:
getresuid() и setresuid() (Linux)Linux предоставляет дополнительные системные вызовы, посредством которых вы можете непосредственно работать с действительными, эффективными и сохраненными ID пользователя и группы:
#include
#include
int getresuid(uid_t *ruid, uid_t *euid, uid_t *suid);
int getresgid(gid_t *rgid, gid_t *egid, gid_t *sgid);
int setresuid(uid_t ruid, uid_t euid, uid_t suid);
int setresgid(gid_t rgid, gid_t egid, gid_t sgid);
Функции следующие:
int getresuid(uid_t *ruid, uid_t *euid, uid_t *suid)
Получает значения действительного, эффективного и сохраненного set-user ID. Возвращаемое значение 0 в случае успеха и -1 при ошибке, errno указывает проблему.
int getresgid(gid_t *rgid, gid_t *egid, gid_t *sgid)
Получает значения действительного, эффективного и сохраненного set-group ID. Возвращаемое значение 0 в случае успеха и -1 при ошибке, errno обозначает проблему.
int setresuid(uid_t ruid, uid_t euid, uid_t suid)
Устанавливает значения действительного, эффективного и сохраненного set-user ID соответственно. Когда значение параметра равно -1, соответствующий UID остается без изменения.
Когда процесс действует как root, параметрами могут быть любые произвольные значения. Однако, использование ненулевого значения для euid вызывает постоянную, безвозвратную утерю привилегии root). В противном случае параметры должны быть одним из значений действительного, эффективного или сохраненного set-user ID.
int setresgid(gid_t rgid, gid_t egid, gid_t sgid)
Устанавливает значения действительного, эффективного и сохраненного set-group ID соответственно. Когда значение параметра равно -1, соответствующий GID остается без изменений.
Эта функция аналогична setresuid().
Функции setresuid() и setresgid() особенно ценны, поскольку их семантика ясно определена. Программист точно знает, каким может быть результат их вызова.
Более того, вызовы являются операциями типа «все или ничего»: они либо полностью успешны в осуществлении нужного изменения, либо терпят полную неудачу, оставляя текущее состояние как есть. Это повышает надежность, поскольку, опять-таки можно быть точно уверенным в том, что случилось.
