Управление процессами

Запуск приложения от имени владельца файла приложения

Обычно эффективные идентификаторы владельца и группы процесса достаются процессу по наследству от процесса-родителя. Но в некоторых ситуациях необходимо запустить программу с правами, большими, нежели права запускающего ее пользователя. Например, вам надо изменить свой пароль. Для этого требуется осуществить запись в файл /etc/shadow. С другой стороны, нельзя давать каждому пользователю такое право: вдруг он поменяет не только свой пароль? Кто откажется сделать милый сюрприз коллеге? Как быть? Если вы подумали, что выход в том, чтобы все пароли менял только администратор, вы далеки от истины.

Идея в том, чтобы право записи в /etc/shadow дать не конкретному пользователю, а программе passwd (как нам известно, пароль меняет именно эта программа). К сожалению, в UNIX нет механизма, который позволяет давать какие-либо права отдельному процессу или приложению. Поэтому право записи в /etc/shadow дали пользователю root (назначив его владельцем этого файла и разрешив запись в файл владельцу - вы помните, как это сделать с помощью chmod?), а программу passwd разрешили всем запускать от имени ее владельца - root.

Это право (запускать программу от имени владельца) является специальным правом доступа к файлу, оно называется SUID (set User ID). Фактически, файл с установленным битом SUID, отвечающим за это право доступа, всегда запускается на выполнение с эффективным идентификатором владельца процесса, равным идентификатору владельца файла.

Как мы помним, полный вид слова прав доступа таков:

su sg  t   r  w  x  r   w  x  r   w  x

Старшие три бита - SUID ( su ), SGID ( sg ) и sticky bit ( t ).

Suid и Sgid

Установить бит suid или sgid можно, указав chmod права доступа в числовом виде:

chmod 4755 файл

или в мнемоническом виде:

chmod u+s файл

В некоторых системах UNIX доступна только одна из этих двух форм.

Бит установки эффективного группового идентификатора (SGID) при запуске файла на выполнение действует сходным с SUID образом: как и в случае бита SUID, установленный SGID вызывает присвоение процессу, исполняемый код которого содержится в запущенном файле, эффективного идентификатора группы, равного идентификатору группы этого файла.

В выводе команды ls файлы с установленными битами SUID и SGID отличаются от прочих тем, что в поле, где обычно стоит "x" (бит выполняемости), оказывается символ "s":

-r-xr-sr-x 1 roottty 10040 Nov 4 2002 /usr/sbin/wall
-r-sr-sr-x 1 rootsys 22168 Nov 4 2002 /usr/bin/passwd

Это означает, что присутствуют оба бита: и бит запускаемости, и бит SUID (или SGID, соответственно). Если попытаться установить бит SUID или SGID на файл, для которого в соответствующем праве доступа (владельца или группы) не будет бита запускаемости, то система не даст это сделать. Поскольку для каталога биты SUID и SGID имеют другое значение, то биты SUID/SGID и биты права поиска в каталоге могут быть установлены по отдельности. В выводе ls в правах доступа к каталогу при отсутствии права поиска и наличии битов SUID/SGID буква S в выводе прав доступа будет заглавной:

dr-Sr-xr-x  2  root  other  512  May  10  01:48  enum
-rw-r--r--  1  root  other  0    May  10  01:47  q

Обратите внимание на права доступа к каталогу enum. Объяснение смысла SUID/SGID для каталога дано в лекции 6.

Найти все файлы, у которых установлен бит SUID, можно с помощью команды

find / -perm -u+s

а файлы с установленным битом SGID - по команде

find / -perm -g+s

Чтобы не допустить взлома системы, относитесь внимательно к файлам, права доступа к которым разрешают запускать их от чужого имени. Появление таких файлов в системе может облегчить жизнь взломщику. Программа passwd, например, написана таким образом, что запускающий ее пользователь не сможет с ее помощью сделать ничего, кроме изменения собственного пароля. Поэтому ей можно доверить запускаться с правами пользователя root. Но где гарантия, что все остальные программы с установленным SUID такие же? Устанавливайте бит SUID только тем программам, которым доверяете на все сто!

Появление новых файлов с <подозрительными> правами доступа может говорить о попытке взлома системы, поэтому при инсталляции некоторых ОС автоматически устанавливается простой сценарий, использующий вышеописанную команду поиска таких файлов для отслеживания добавленных за последние сутки файлов с установленным битом SUID. Например, во FreeBSD это делается в сценарии /etc/daily, ежедневно проверяющем состояние системы.

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

Интерактивные и фоновые процессы

Процесс в UNIX может быть интерактивным и фоновым. Процесс, который имеет доступ к вводу с терминала и к выводу на него, называется интерактивным (foreground). Таким процессом является почтовая программа mail, редактор текста vi и другие программы. Фоновый процесс не имеет доступа к вводу с терминала, и имеет условный доступ к выводу на терминал. Условие состоит в том, что вывод на терминал разрешен фоновому процессу, если терминал настроен для работы в режиме tostop . Эту настройку можно выполнить командой

stty -tostop

Обратная настройка выполняется командой

stty tostop

Если фоновый процесс пытается выводить что-либо на терминал, настроенный для работы в режиме tostop, то процессу посылается сигнал SIGSTOP. Процесс, получивший такой сигнал, останавливается (переводится в состояние STOPPED ).

Если фоновый процесс начинает выполнять вывод на терминал в то время, когда вы работаете в текстовом редакторе или подобной программе, текст на экране может перемешаться. Это не беда: на фактическое содержание редактируемого файла это никакого влияния не оказывает. В большинстве полноэкранных программ под UNIX достаточно нажать Ctrl-L, чтобы обновить экран, и назойливые сообщения исчезнут.

Для запуска фонового процесса из командного интерпретатора следует дать команду, завершив ее знаком "&" (амперсэнд):

команда &

Можно запустить сборку пакета программ в фоновом режиме, и пока он собирается, выполнять другую работу:

make all &