Процессы и память в Linux. Отрывок из книги «Внутреннее устройство Linux»

О книге

Сов­сем недав­но в изда­тель­стве БХВ выш­ло вто­рое изда­ние кни­ги Дмит­рия Кетова «Внут­реннее устрой­ство Linux». Я про­чел пре­дос­тавлен­ный изда­тель­ством экзем­пляр и сде­лал свои выводы о качес­тве кни­ги, ее плю­сах и целевой ауди­тории. В при­дачу мы пуб­лику­ем отры­вок кни­ги, который поз­волит тебе сос­тавить собс­твен­ное мне­ние.

Нес­мотря на гром­кое наз­вание, эта кни­га — не об устрой­стве Linux. Из нее ты не узна­ешь, как работа­ет сис­тема управле­ния вир­туаль­ной памятью ядра Linux или фай­ловая сис­тема Btrfs. Эта кни­га — ско­рее учеб­ник «GNU/Linux для про­дол­жающих», то есть тех, кто понял, что такое коман­дный интер­пре­татор и пра­ва дос­тупа, но хотел бы коп­нуть глуб­же и понять, почему этот интер­пре­татор имен­но такой, с какой целью появил­ся инс­тру­мент sudo и почему, нес­мотря на весь хейт, менед­жер Systemd стал стан­дартом.

Глав­ное дос­тоинс­тво кни­ги — гра­мот­ное балан­сирова­ние меж­ду теорией и прак­тикой. Автор соп­ровож­дает текст боль­шим количес­твом исто­ричес­ких спра­вок и деталей, которые быва­ют нез­накомы даже мне, умуд­ренно­му двад­цатилет­ним опы­том линук­соиду. При этом прак­тичес­ки каж­дое выс­казыва­ние авто­ра соп­ровож­дает­ся при­мером, пояс­няющим теорию. Хочешь уви­деть, как работа­ют управля­ющие пос­ледова­тель­нос­ти тер­минала? Вот тебе лис­тинг команд с отметка­ми, где, что и как надо нажать.

Вто­рой плюс — пол­нота информа­ции. Нес­мотря на мас­су под­робнос­тей о реали­зации ком­понен­тов типич­ного дис­три­бути­ва и срав­нитель­но неболь­шой объ­ем, кни­га охва­тыва­ет прак­тичес­ки все, что может быть инте­рес­но поль­зовате­лю, начиная от эму­лято­ра тер­минала и коман­дно­го интер­пре­тато­ра и закан­чивая гра­фичес­кой сис­темой Wayland, которая толь­ко готовит­ся занять мес­то стан­дар­тной в дис­три­бути­вах Linux, пла­ниров­щиком BFQ и кон­тей­нер­ной сис­темой Docker, о которых ты не узна­ешь из более «ака­деми­чес­кой» и «про­верен­ной вре­менем» литера­туры.

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

— Ев­гений Зоб­нин

Программы и библиотеки

Прог­рамма пред­став­ляет собой ал­горитм, записан­ный на опре­делен­ном язы­ке, понят­ном исполни­телю прог­раммы. Раз­лича­ют машин­ный язык, понят­ный цен­траль­ному про­цес­сору, и язы­ки более высоких уров­ней (алго­рит­мичес­кие), понят­ные сос­тавите­лю прог­раммы — прог­раммис­ту.

Прог­раммы, сос­тавлен­ные на язы­ке высоко­го уров­ня, в любом слу­чае перед исполне­нием дол­жны быть тран­сли­рова­ны (переве­дены) на язык исполни­теля, что реали­зует­ся при помощи спе­циаль­ных средств — тран­сля­торов. Раз­лича­ют два вида тран­сля­торов прог­рамм — ком­пилято­ры и ин­тер­пре­тато­ры. Ком­пилятор тран­сли­рует в машин­ный код сра­зу целиком всю прог­рамму и не учас­тву­ет в ее исполне­нии. Интер­пре­татор, наобо­рот, пошаго­во тран­сли­рует отдель­ные инс­трук­ции прог­раммы и немед­ленно выпол­няет их. Нап­ример, ко­ман­дный интер­пре­татор при инте­рак­тивном режиме пошаго­во выпол­няет коман­ды, вво­димые поль­зовате­лем, а в пакет­ном режиме так же пошаго­во выпол­няет коман­ды, записан­ные в фай­ле сце­нария.

Ал­горитм, в свою оче­редь, есть некото­рый набор инс­трук­ций, выпол­нение которых при­водит к решению кон­крет­ной задачи. В боль­шинс­тве слу­чаев инс­трук­ции алго­рит­ма име­ют при­чин­но‑следс­твен­ные зависи­мос­ти и выпол­няют­ся исполни­телем пос­ледова­тель­но. Одна­ко если выделить «незави­симые» под­наборы инс­трук­ций (незави­симые вет­ви), то их мож­но выпол­нять нес­коль­кими исполни­теля­ми одновре­мен­но — па­рал­лель­но. Поэто­му раз­лича­ют пос­ледова­тель­ные и парал­лель­ные алго­рит­мы и соот­ветс­тву­ющие им пос­ледова­тель­ные и парал­лель­ные прог­раммы. Некото­рые прог­раммы реали­зуют алго­рит­мы обще­го наз­начения, нап­ример алго­рит­мы сжа­тия или шиф­рования информа­ции, алго­рит­мы сетевых про­токо­лов и т. д. Такие прог­раммы, вос­тре­бован­ные не столь­ко конеч­ными поль­зовате­лями, сколь­ко дру­гими прог­рамма­ми, называ­ют биб­лиоте­ками.

Сог­ласно hier, откомпи­лиро­ван­ные до машин­ного язы­ка прог­раммы раз­меща­ются в катало­гах /bin, /sbin, /usr/bin, /usr/sbin, /usr/local/bin, /usr/local/sbin, а биб­лиоте­ки — в катало­гах /lib, /usr/lib, /usr/local/lib. Прог­раммы име­ют спе­циаль­ный бинар­ный «запус­каемый» фор­мат W:[ELF] executable и зависят от биб­лиотек, что про­иллюс­три­рова­но в сле­дующем лис­тинге при помощи коман­ды ldd (loader dependencies). Каж­дая зависи­мость отоб­ража­ется име­нем биб­лиоте­ки ❶ (SONAME, shared object name), най­ден­ным в сис­теме фай­лом биб­лиоте­ки ❷ и адре­сом в памяти про­цес­са ❸ (32- или 48-бит­ным, в зависи­мос­ти от плат­формы), куда биб­лиоте­ка будет заг­ружена.

Прог­раммы и биб­лиоте­ки

Нуж­но заметить, что фай­ла биб­лиоте­ки linux-vdso.so.1 (реали­зующей интерфейс сис­темных вызовов к ядру) не сущес­тву­ет, так как она явля­ется вир­туаль­ной (VDSO, virtual dynamic shared object), т. е. пре­дос­тавля­ется и отоб­ража­ется в память про­цес­са самим ядром, «как буд­то» явля­ется нас­тоящей биб­лиоте­кой. Кро­ме того, биб­лиоте­ка ld-linux-x86-64.so.2 ука­зана абсо­лют­ным путевым име­нем, поэто­му поиск ее фай­ла не про­изво­дит­ся.

Для боль­шинс­тва биб­лиотек зависи­мость уста­нав­лива­ется при помощи SONAME вида libNAME.so.X, где lib — стан­дар­тный пре­фикс (library, биб­лиоте­ка), .so — суф­фикс (shared object, раз­деля­емый объ­ект), NAME — имя «собс­твен­ное», а .X — номер вер­сии ее интерфей­са. По име­ни SONAME в опре­делен­ных (кон­фигура­цией ком­понов­щика) катало­гах про­изво­дит­ся поиск одно­имен­ного фай­ла биб­лиоте­ки, который на самом деле ока­зыва­ется сим­воличес­кой ссыл­кой ❹ на «нас­тоящий» файл биб­лиоте­ки. Нап­ример, для 6-й вер­сии интерфей­са динами­чес­кой биб­лиоте­ки язы­ка с (libc.so.6) нас­тоящий файл биб­лиоте­ки называ­ется libc2.30.so, что ука­зыва­ет на вер­сию самой биб­лиоте­ки как 2.30.

Вер­сии биб­лиотек

Ана­логич­но, в при­веден­ном выше лис­тинге показа­но, что для 0-й вер­сии интерфей­са динами­чес­кой биб­лиоте­ки регуляр­ных perl-выраже­ний pcre2 (libpcre2-8.so.0) нас­тоящий файл биб­лиоте­ки называ­ется libpcre2-8.so.0.7.1, а это ука­зыва­ет на вер­сию самой биб­лиоте­ки как 0.7.1.

Та­кой под­ход поз­воля­ет заменять (исправ­лять ошиб­ки, улуч­шать неэф­фектив­ные алго­рит­мы и пр.) биб­лиоте­ки (при усло­вии неиз­меннос­ти их интерфей­сов) от­дель­но от прог­рамм, завися­щих от них. При обновле­нии биб­лиоте­ки libc2.30.so, нап­ример, до libc2.32.so дос­таточ­но уста­новить сим­воличес­кую SONAME-ссыл­ку libc.so.6 на libc-2.32.so, в резуль­тате чего ее нач­нут исполь­зовать все прог­раммы с зависи­мос­тями от libc.so.6. Более того, в сис­теме может быть одновре­мен­но уста­нов­лено любое количес­тво вер­сий одной и той же биб­лиоте­ки, реали­зующих оди­нако­вые или раз­ные вер­сии интерфей­сов, выбор которых будет ука­зан соот­ветс­тву­ющи­ми SONAME-ссыл­ками.

Биб­лиоте­ки — это незапус­каемые прог­раммы

Биб­лиоте­ки име­ют тот же бинар­ный фор­мат W:[ELF], что и «запус­каемые» прог­раммы, но не «запус­каемый» executable, а «сов­мес­тно исполь­зуемый» shared object. Биб­лиоте­ки, явля­ясь пусть и незапус­каемы­ми, но прог­рамма­ми, естес­твен­ным обра­зом тоже зависят от дру­гих биб­лиотек, что показа­но в сле­дующем лис­тинге. Прак­тичес­ки «запус­каемость» ELF-фай­лов зависит не от их типа, а от прав дос­тупа и осмыслен­ности точ­ки вхо­да — адре­са пер­вой инс­трук­ции, которой переда­ется управле­ние при попыт­ке запус­ка. Нап­ример, биб­лиоте­ку libc-2.30.so мож­но запус­тить, в резуль­тате чего будет выведе­на ста­тус­ная информа­ция.

За­пус­каемые биб­лиоте­ки

Ядро Linux

Не сто­ит забывать, что самой глав­ной прог­раммой опе­раци­онной сис­темы явля­ется ее ядро, которое в Linux сос­тоит из ста­тичес­кого стар­тового модуля в фор­мате ELF executable и динами­чес­ки прис­тыковы­ваемых прог­рам­мных модулей фор­мата ELF relocatable. Для выпол­нения про­цеду­ры началь­ной заг­рузки стар­товый модуль упа­кован в «саморас­паковы­вающий­ся» gzip-архив фор­мата bzImage (big zipped image), который сос­тоит из прог­раммы рас­паков­ки и собс­твен­но запако­ван­ного стар­тового модуля.

В при­веден­ном ниже лис­тинге про­иллюс­три­рован про­цесс извле­чения стар­тового модуля из архи­ва /boot/vmlinuz-3.13.0-49-generic фор­мата bzImage ⓿, который пред­варитель­но копиру­ется ❶ в /tmp/vmlinuz. Для извле­чения исполь­зует­ся сце­нарий extract-vmlinux ❷ из пакета заголо­воч­ных фай­лов ядра. Рас­пакован­ный ❸ стар­товый модуль /tmp/vmlinux ожи­даемо ока­зыва­ется ста­тичес­ки ском­понован­ной (т. е. не исполь­зующей биб­лиоте­ки ELF shared object) исполня­емой ELF-прог­раммой.

Яд­ро опе­раци­онной сис­темы

Ди­нами­чес­кие модули заг­ружа­ются в прос­транс­тво ядра и прис­тыковы­вают­ся к стар­товому модулю поз­днее, уже при работе опе­раци­онной сис­темы при помощи сис­темных ути­лит insmod или modprobe. Для отсты­ков­ки и выг­рузки ненуж­ных модулей пред­назна­чена сис­темная ути­лита rmmod, для прос­мотра спис­ка ❶ заг­ружен­ных модулей — lsmod, а для иден­тифика­ции свой­ств и парамет­ров ❷ модулей — ути­лита modinfo. Заг­рузка и выг­рузка модулей реали­зует­ся спе­циаль­ными сис­темны­ми вызова­ми init_module и delete_module, дос­туп к спис­ку заг­ружен­ных модулей — при помощи фай­ла /proc/modules псев­дофай­ловой сис­темы proc, а иден­тифика­ция свой­ств и парамет­ров модулей — чте­нием спе­циаль­ных сек­ций ELF-фай­лов модулей.

Модули ядра

Ди­нами­чес­кие модули ядра зачас­тую явля­ются драй­верами устрой­ств, что про­иллюс­три­рова­но в лис­тинге при помощи ути­лит lspci и lsusb, которые ска­ниру­ют пос­редс­твом псев­дофай­ловой сис­темы sysfs спис­ки обна­ружен­ных ядром на шинах PCI и USB устрой­ств и обслу­жива­ющих их драй­веров.

Драй­веры устрой­ств

Процессы и нити

Сущ­ность про­цес­са нераз­рывно свя­зана с муль­тип­рограм­мирова­нием и мно­гоза­дач­ностью опе­раци­онной сис­темы. Нап­ример, в одно­задач­ных опе­раци­онных сис­темах прог­раммы сущес­тву­ют, а про­цес­сы — нет. В одно­задач­ных опе­раци­онных сис­темах еди­нов­ремен­но одна пос­ледова­тель­ная прог­рамма выпол­няет­ся одним исполни­телем (цен­траль­ным про­цес­сором), имея воз­можность без­раздель­но исполь­зовать все дос­тупные ресур­сы (память, устрой­ства вво­да‑вывода и пр.).

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

Ис­поль­зуя такую модель поведе­ния прог­рамм, мож­но про­вес­ти ана­лиз пот­ребле­ния ими ресур­сов при выпол­нении. Нап­ример, ком­прес­соры gzip, bzip и xz счи­тыва­ют оче­ред­ной блок дан­ных исходно­го фай­ла, отно­ситель­но дол­го упа­ковы­вают его и записы­вают в резуль­тиру­ющий файл, а затем пов­торя­ют про­цеду­ру до исчерпа­ния бло­ков исходно­го фай­ла. Количес­тво вре­мени, пот­рачен­ного на вычис­литель­ные опе­рации упа­ков­ки, будет мно­го боль­ше количес­тва вре­мени, пот­рачен­ного на чте­ние исходных дан­ных и запись резуль­татов, поэто­му наг­рузка на ЦП будет высокой, а на УВВ — нет. Такой же ана­лиз мож­но при­вес­ти и для дуб­ликато­ра dd, копиров­щика rsync или архи­вато­ра tar, которые, наобо­рот, поч­ти не выпол­няют никаких вычис­лений, а сос­редото­чены на вво­де‑выводе боль­ших объ­емов дан­ных, поэто­му при их исполь­зовании наг­рузка на ЦП будет доволь­но низ­кой, а на УВВ — высокой.

Для коман­дно­го интер­пре­тато­ра bash, тек­сто­вых редак­торов nano и vim и дру­гих инте­рак­тивных прог­рамм, вза­имо­дей­ству­ющих с поль­зовате­лем, харак­терны дли­тель­ные ожи­дания вво­да неболь­ших команд, прос­тая и недол­гая их обра­бот­ка и вывод корот­кого резуль­тата. В резуль­тате коэф­фици­ент полез­ного исполь­зования и ЦП, и УВВ будет приб­лижен к нулю.

По­доб­ный ана­лиз и желание уве­личить коэф­фици­енты полез­ного исполь­зования ресур­сов при­вели к соз­данию мно­гоза­дач­ных опе­раци­онных сис­тем, осно­выва­ющих­ся на прос­той идее псев­доод­новре­мен­ного выпол­нения нес­коль­ких пос­ледова­тель­ных прог­рамм одним исполни­телем. Для это­го вмес­то прос­тоя в ожи­дании окон­чания опе­рации вво­да‑вывода, начатой некото­рой прог­раммой, цен­траль­ный про­цес­сор перек­люча­ется на выпол­нение дру­гой прог­раммы, тем самым уве­личи­вая интеграль­ный коэф­фици­ент его полез­ного исполь­зования.

С появ­лени­ем муль­тип­рограм­мной сме­си (так называ­ют набор прог­рамм, меж­ду которы­ми перек­люча­ется про­цес­сор) каж­дая из ее прог­рамм боль­ше не может без­раздель­но исполь­зовать все дос­тупные ресур­сы (нап­ример, всю память — она одновре­мен­но нуж­на всем прог­раммам сме­си), в свя­зи с чем опе­раци­онная сис­тема берет на себя задачи дис­петче­риза­ции (рас­пре­деле­ния) ресур­сов меж­ду ними. В Linux, как и во мно­гих дру­гих опе­раци­онных сис­темах, прог­раммы изо­лиру­ются друг от дру­га в спе­циаль­ных «вир­туаль­ных» сре­дах, обес­печива­ющих их про­цесс выпол­нения. Каж­дая такая сре­да называ­ется про­цес­сом и получа­ет долю дос­тупных ресур­сов — выделен­ный учас­ток памяти, выделен­ные про­межут­ки про­цес­сорно­го вре­мени. Про­цесс эму­лиру­ет для прог­раммы «одно­задач­ный» режим выпол­нения, слов­но прог­рамма выпол­няет­ся в оди­ноч­ку, и «без­раздель­ное» исполь­зование ресур­сов про­цес­са, как буд­то это все дос­тупные ресур­сы.

Па­рал­лель­ные прог­раммы, как ука­зыва­лось ранее, сос­тоят из незави­симых вет­вей, каж­дая из которых сама по себе укла­дыва­ется в модель поведе­ния пос­ледова­тель­ной прог­раммы, поэто­му одну парал­лель­ную прог­рамму мож­но выпол­нять в нес­коль­ких про­цес­сах в псев­доод­новре­мен­ном режиме. Про­цес­сы опе­раци­онной сис­темы, таким обра­зом, явля­ются кон­тей­нерами для мно­гоза­дач­ного выпол­нения прог­рамм, как пос­ледова­тель­ных, так и парал­лель­ных.

В сле­дующем лис­тинге при помощи коман­ды ps показа­ны про­цес­сы поль­зовате­ля, упо­рядо­чен­ные в дерево, пос­тро­енное на осно­ве дочер­не‑родитель­ских отно­шений меж­ду про­цес­сами. Уни­каль­ный иден­тифика­тор, отли­чающий про­цесс от дру­гих, выведен в стол­бце PID (process identifier), а имя и аргу­мен­ты прог­раммы, запущен­ной в соот­ветс­тву­ющем про­цес­се — в стол­бце COMMAND.

В стол­бце STAT показа­но текущее сос­тояние про­цес­са, нап­ример S (сон, sleep) или R (выпол­нение, running, или готов­ность к выпол­нению, runnable). Про­цес­сы, ожи­дающие завер­шения их опе­раций вво­да‑вывода, находят­ся в сос­тоянии сна, в про­тив­ном слу­чае либо выпол­няют­ся, либо готовы к выпол­нению, т. е. ожи­дают, ког­да текущий выпол­няющий­ся про­цесс зас­нет и про­цес­сор будет перек­лючен на них. В стол­бце TIME показа­но чис­тое пот­реблен­ное про­цес­сом про­цес­сорное вре­мя от момен­та запус­ка прог­раммы, уве­личи­вающееся толь­ко при нахож­дении им в сос­тоянии выпол­нения.

Де­рево про­цес­сов поль­зовате­ля

Уп­равля­ющий тер­минал про­цес­са, показан­ный в стол­бце TTY, исполь­зует­ся для дос­тавки ему инте­рак­тивных сиг­налов (см. разд. 4.8) при вво­де управля­ющих сим­волов intr ^C, quit ^\ и пр. у час­ти про­цес­сов ⓿, ❸ управля­ющий тер­минал отсутс­тву­ет, потому что они выпол­няют при­ложе­ния, вза­имо­дей­ству­ющие с поль­зовате­лем не пос­редс­твом тер­миналов, а через гра­фичес­кую сис­тему.

Про­цесс по сво­ему опре­деле­нию изо­лиру­ет свою прог­рамму от дру­гих выпол­няющих­ся прог­рамм, что зат­рудня­ет исполь­зование про­цес­сов для выпол­нения таких парал­лель­ных прог­рамм, вет­ви которых не явля­ются пол­ностью незави­симы­ми друг от дру­га и дол­жны обме­нивать­ся дан­ными. Исполь­зование пред­назна­чен­ных для это­го средств меж­про­цес­сно­го вза­имо­дей­ствия при интенсив­ном обме­не при­водит к обре­мене­нию неоп­равдан­ными нак­ладны­ми рас­ходами, поэто­му для эффектив­ного выпол­нения таких парал­лель­ных прог­рамм исполь­зуют­ся лег­ковес­ные про­цес­сы (LWP, light-weight processes), они же нити (threads).

Ме­ханизм нитей поз­воля­ет перек­лючать цен­траль­ный про­цес­сор меж­ду парал­лель­ными вет­вями одной прог­раммы, раз­меща­емы­ми в од­ном (!) про­цес­се. Нити никак не изо­лиро­ваны друг от дру­га, и им дос­тупны абсо­лют­но все ресур­сы сво­его про­цес­са, поэто­му задача обме­на дан­ными меж­ду нитями поп­росту отсутс­тву­ет, т. к. все дан­ные явля­ются для них общи­ми.

В при­мере из cktle.otuj сле­дующе­го лис­тинга показа­ны нити про­цес­са в BSD-фор­мате вывода. Выбор про­цес­са про­изво­дит­ся по его иден­тифика­тору PID, пред­варитель­но получен­ному коман­дой pgrep по име­ни прог­раммы, выпол­няющей­ся в иско­мом про­цес­се.

В выводе наличие нитей про­цес­са отме­чает флаг l (lwp) в стол­бце сос­тояния STAT, а каж­дая строч­ка без иден­тифика­тора PID сим­волизи­рует одну нить. Так как в мно­гони­тевой прог­рамме перек­лючение про­цес­сора про­изво­дит­ся меж­ду нитями, то и сос­тояния сна S, выпол­нения или ожи­дания R при­писы­вают­ся отдель­ным нитям.

Ни­ти про­цес­сов, BSD-фор­мат вывода

В нижес­леду­ющем лис­тинге показа­ны нити про­цес­са в SYSV-фор­мате вывода. Выбор про­цес­са про­изво­дит­ся по име­ни его прог­раммы. Общий для всех нитей иден­тифика­тор их про­цес­са отоб­ража­ется в стол­бце PID, уни­каль­ный иден­тифика­тор каж­дой нити — в стол­бце LWP (иног­да называ­емый TID, thread identifier), а имя про­цес­са (или собс­твен­ное имя нити, если задано) — в стол­бце CMD.

Ни­ти про­цес­сов, SYSV-фор­мат вывода

Порождение процессов и нитей, запуск программ

Нес­мотря на оче­вид­ные раз­личия, исто­рию воз­никно­вения и раз­вития, нити и про­цес­сы объ­еди­няет общее наз­начение — они явля­ются при­мити­вами выпол­нения некото­рого набора пос­ледова­тель­ных инс­трук­ций. Откро­вен­но говоря, нити, в общем, появи­лись в опе­раци­онных сис­темах рань­ше, чем изо­лиро­ван­ные UNIX-про­цес­сы, в которые со вре­менем вер­нулись UNIX-нити.

Про­цес­сы выпол­няют или раз­ные пос­ледова­тель­ные прог­раммы целиком, или вет­ви одной парал­лель­ной прог­раммы, но в изо­лиро­ван­ном окру­жении со сво­им «час­тным» (private) набором ресур­сов. Нити, наобо­рот, выпол­няют вет­ви одной парал­лель­ной прог­раммы в одном окру­жении с «общим» (shared) набором ресур­сов. В мно­гоза­дач­ном ядре Linux вооб­ще исполь­зует­ся уни­вер­саль­ное понятие «задача», которая может иметь как общие ресур­сы (память, откры­тые фай­лы и т. д.) с дру­гими задача­ми, так и час­тные ресур­сы для сво­его собс­твен­ного исполь­зования.

По­рож­дение нового про­цес­са реали­зует­ся при помощи сис­темно­го вызова fork, в резуль­тате которо­го ядро опе­раци­онной сис­темы соз­дает новый дочер­ний (child) про­цесс PID² — пол­ную копию (COPY) про­цес­са‑родите­ля (parent) PID^1. Вся (за неболь­шими исклю­чени­ями) память про­цес­са — сос­тояние, свой­ства, атри­буты (кро­ме иден­тифика­тора PID) и даже содер­жимое (прог­рамма с ее биб­лиоте­ками) — нас­леду­ется дочер­ним про­цес­сом. Даже выпол­нение порож­денно­го и порож­дающе­го про­цес­са про­дол­жится с одной и той же инс­трук­ции их оди­нако­вой прог­раммы. Такое кло­ниро­вание обыч­но исполь­зуют парал­лель­ные прог­раммы с вет­вями, выпол­няющи­мися в дочер­них про­цес­сах.

Унич­тожение про­цес­са (нап­ример, при штат­ном окон­чании прог­раммы) про­изво­дит­ся с помощью сис­темно­го вызова exit. При этом родитель­ско­му про­цес­су дос­тавля­ется сиг­нал SIGCHILD, опо­веща­ющий о завер­шении дочер­него про­цес­са. Ста­тус завер­шения status, передан­ный дочер­ним про­цес­сом через аргу­мен­ты exit, будет сох­ранять­ся ядром до момен­та его вос­тре­бова­ния родитель­ским про­цес­сом при помощи сис­темно­го вызова wait, а весь этот про­межу­ток вре­мени дочер­ний про­цесс будет находить­ся в сос­тоянии Z (zombie).

Ро­дитель­ский про­цесс может завер­шить­ся рань­ше сво­их дочер­них про­цес­сов, тог­да логич­но пред­положить, что все «оси­ротев­шие» про­цес­сы ока­жут­ся зом­би по завер­шении, потому как прос­то некому будет вос­тре­бовать их ста­тус завер­шения. На самом деле это­го не про­исхо­дит, потому что «оси­ротев­шим» про­цес­сам наз­нача­ется при­емный родитель, в качес­тве которо­го выс­тупа­ет пра­роди­тель всех про­цес­сов init с иден­тифика­тором PID = 1.

За­пуск новой прог­раммы (см. рис.) реали­зует­ся при помощи сис­темно­го вызова exec, в резуль­тате которо­го содер­жимое про­цес­са PID¹ пол­ностью замеща­ется запус­каемой прог­раммой и биб­лиоте­ками, от которых она зависит, а свой­ства и атри­буты (вклю­чая иден­тифика­тор PID) оста­ются неиз­менны­ми. Такое замеще­ние обыч­но исполь­зует­ся прог­рамма­ми, уста­нав­лива­ющи­ми нуж­ные зна­чения свой­ств и атри­бутов про­цес­са и под­готав­лива­ющи­ми ресур­сы про­цес­са к выпол­нению запус­каемой прог­раммы. Нап­ример, обра­бот­чик тер­миналь­ного дос­тупа getty откры­вает задан­ный тер­минал, уста­нав­лива­ет режимы работы пор­та тер­минала, перенап­равля­ет на тер­минал стан­дар­тные потоки вво­да‑вывода, а затем замеща­ет себя прог­раммой аутен­тифика­ции login.

Для запус­ка новой прог­раммы в новом про­цес­се исполь­зуют­ся оба сис­темных
вы­зова fork и exec сог­ласно прин­ципу fork-and-exec «раз­дво­ить­ся и запус­тить», показан­ного на рисун­ке ниже. Нап­ример, коман­дный интер­пре­татор bash по коман­дам ps fx или man ps порож­дает дочер­ние про­цес­сы ❷ и замеща­ет их прог­рамма­ми ps и man. Тем же обра­зом дей­ству­ет ⓿ гра­фичес­кий эму­лятор тер­минала gnome-terminal-server — запус­кая новый сеанс поль­зовате­ля ❶ на каж­дой из сво­их вкла­док, он замеща­ет свои дочер­ние про­цес­сы прог­раммой интер­пре­тато­ра bash.

Сле­дующий лис­тинг иллюс­три­рует коман­ду интер­пре­тато­ра, запущен­ную в «фоновом» режиме при помощи конс­трук­ции асин­хрон­ного спис­ка. Ана­логич­но всем пре­дыду­щим коман­дам, интер­пре­татор исполь­зует fork-and-exec для запус­ка прог­раммы в дочер­нем про­цес­се с иден­тифика­тором 23228, но не дожида­ется его завер­шения при помощи сис­темно­го вызова wait, как обыч­но, а немед­ленно ❶ про­дол­жает инте­рак­тивное вза­имо­дей­ствие с поль­зовате­лем, сооб­щив ему PID порож­денно­го про­цес­са и «номер задания» [1] коман­ды «зад­него фона». Опо­веще­ние о завер­шении сво­его дочер­него про­цес­са интер­пре­татор получит поз­же, при помощи сиг­нала SIGCHLD, и отре­аги­рует соот­ветс­тву­ющим сооб­щени­ем ❷ об окон­чании коман­ды «зад­него фона».

Фо­новое выпол­нение прог­рамм

В сле­дующем лис­тинге показа­на кон­вей­ерная конс­трук­ция интер­пре­тато­ра, при помощи которой осу­щест­вля­ется поиск самого боль­шого фай­ла с суф­фиксом .html вниз по дереву катало­гов, начиная с /usr/share/doc. Эта конс­трук­ция реали­зует­ся при помощи fork-and-exec четырь­мя парал­лель­но порож­денны­ми дочер­ними про­цес­сами интер­пре­тато­ра, в каж­дом из которых запуще­на прог­рамма соот­ветс­тву­ющей час­ти кон­вей­ера, при этом дочер­ние про­цес­сы свя­заны неиме­нован­ным каналом pipe — прос­тей­шим средс­твом меж­про­цес­сно­го вза­имо­дей­ствия. Встро­енная коман­да интер­пре­тато­ра wait реали­зует одно­имен­ный сис­темный вызов и исполь­зует­ся для ожи­дания окон­чания всех дочер­них про­цес­сов кон­вей­ера, целиком запущен­ного в «фоновом» режиме.

Па­рал­лель­ный запуск вза­имо­дей­ству­ющих прог­рамм

Параллельные многопроцессные программы

Как ука­зыва­лось ранее, парал­лель­ные прог­раммы зачас­тую исполь­зуют про­цес­сы для выпол­нения отдель­ных вет­вей. В эту катего­рию час­то попада­ют прог­раммы сетевых служб, нап­ример сер­вер баз дан­ных W:[PostgreSQL], служ­ба уда­лен­ного дос­тупа W:[SSH] и подоб­ные. Сле­дующий лис­тинг иллюс­три­рует прог­рамму postgres, выпол­няющуюся в шес­ти парал­лель­ных про­цес­сах, один из которых — дис­петчер ❶, четыре слу­жеб­ных ❷ и еще один ❸ выз­ван под­клю­чени­ем поль­зовате­ля fitz к одно­имен­ной базе дан­ных fitz. При пос­леду­ющих под­клю­чени­ях поль­зовате­лей к сер­веру будут порож­дены допол­нитель­ные дочер­ние про­цес­сы для обслу­жива­ния их зап­росов — по одно­му на каж­дое под­клю­чение.

Па­рал­лель­ные мно­гоп­роцес­сные сер­висы

Ана­логич­но, при уда­лен­ном дос­тупе по про­токо­лу SSH прог­рамма sshd, работая в качес­тве дис­петче­ра ① в одном про­цес­се, на каж­дое под­клю­чение порож­дает один свой клон ②, который, выпол­нив аутен­тифика­цию и авто­риза­цию поль­зовате­ля в сис­теме, порож­дает еще один свой клон ③, имперсо­ниру­ющий­ся в поль­зовате­ля и обслу­жива­ющий его зап­росы.

Параллельные многонитевые программы

Для управле­ния нитями в Linux исполь­зуют стан­дар­тный POSIX-интерфейс pthreads, реали­зующий­ся биб­лиоте­кой W:[NPTL], которая явля­ется частью биб­лиоте­ки libc. Интерфейс пре­дос­тавля­ет «нитевой» вызов соз­дания нити pthread_create, который явля­ется условным ана­логом «про­цес­сных» fork и exec, вызов завер­шения и унич­тожения нити pthread_exit, условно ана­логич­ный exit, и вызов для получе­ния ста­туса завер­шения нити pthread_join, условно ана­логич­ный wait.

В качес­тве типич­ных при­меров при­мене­ния нитей мож­но при­вес­ти сетевые сер­висы, которые для парал­лель­ного обслу­жива­ния кли­ент­ских зап­росов исполь­зуют нити вмес­то про­цес­сов. Нап­ример, WEB-сер­вер apache, как показа­но в сле­дующем лис­тинге, исполь­зует два мно­гони­тевых про­цес­са по 27 нитей в каж­дом, что поз­воля­ет эко­номить память (за счет работы всех нитей про­цес­са с общей памятью) при обслу­жива­нии боль­шого количес­тва одновре­мен­ных кли­ент­ских под­клю­чений.

Па­рал­лель­ные мно­гони­тевые сер­висы

Ана­логич­но, сер­вис цен­тра­лизо­ван­ной жур­нализа­ции событий rsyslogd исполь­зует нити для парал­лель­ного сбо­ра событий­ной информа­ции из раз­ных источни­ков, ее обра­бот­ки и жур­нализа­ции. Одна нить счи­тыва­ет события ядра из /proc/kmsg, вто­рая при­нима­ет события дру­гих служб из фай­лового сокета /run/systemd/journal/syslog (/dev/log в ран­них, до systemd сис­темах), третья филь­тру­ет поток при­нятых событий и записы­вает в жур­наль­ные фай­лы катало­га /var/log/* и т. д. Парал­лель­ная обра­бот­ка потоков пос­тупа­ющих событий при помощи нитей про­изво­дит­ся с минималь­но воз­можны­ми нак­ладны­ми рас­ходами, что поз­воля­ет дос­тигать колос­саль­ной про­изво­дитель­нос­ти по количес­тву обра­баты­ваемых сооб­щений в еди­ницу вре­мени.

Рас­парал­лелива­ние исполь­зует­ся не толь­ко для псев­доод­новре­мен­ного выпол­нения вет­вей парал­лель­ной прог­раммы, но и для их нас­тояще­го одновре­мен­ного выпол­нения нес­коль­кими цен­траль­ными про­цес­сорами. В при­мере из сле­дующе­го лис­тинга показа­но, как сок­раща­ется вре­мя сжа­тия ISO-обра­за фай­ла при исполь­зовании парал­лель­ного упа­ков­щика pbzip2 по срав­нению с пос­ледова­тель­ным bzip2. Для изме­рения вре­мени упа­ков­ки при­меня­ется встро­енная коман­да интер­пре­тато­ра time, при этом сна­чала изме­ряет­ся вре­мя упа­ков­ки ❶ и вре­мя рас­паков­ки ❷ пос­ледова­тель­ным упа­ков­щиком, а затем — вре­мя упа­ков­ки ① и вре­мя рас­паков­ки ② парал­лель­ным упа­ков­щиком. Коман­ды упа­ков­ки запус­кают­ся на «зад­нем фоне», оце­нива­ется наличие про­цес­сов и нитей паков­щиков, пос­ле чего они перево­дят­ся на «перед­ний фон» встро­енной коман­дой интер­пре­тато­ра fg (foreground) и оце­нива­ются зат­раты вре­мени.

Па­рал­лель­ные мно­гони­тевые ути­литы

В резуль­тате оцен­ки ока­зыва­ется, что пос­ледова­тель­ный упа­ков­щик bzip2 исполь­зует один одно­ните­вой про­цесс и зат­рачива­ет ≈54,7 с реаль­ного вре­мени на упа­ков­ку, из них ≈51,7 с про­водит в поль­зователь­ском режиме user и лишь ≈0,4 с в режиме ядра sys (выпол­няя сис­темные вызовы, нап­ример read или write). Соот­ношение меж­ду вре­менем режимов говорит о вычис­литель­ном харак­тере прог­раммы, т. е. о сущес­твен­ном пре­вали­рова­нии вре­мени вычис­литель­ных опе­раций упа­ков­ки над вре­менем опе­раций вво­да‑вывода для чте­ния исходных дан­ных и записи резуль­татов. Это озна­чает, что наг­рузка пос­ледова­тель­ного упа­ков­щика на цен­траль­ный про­цес­сор (в слу­чае, если бы он был единс­твен­ный) близ­ка к мак­сималь­ной, и его парал­лель­ная реали­зация для псев­доод­новре­мен­ного выпол­нения вет­вей (которые прак­тичес­ки никог­да не спят) лишена смыс­ла.

Па­рал­лель­ный упа­ков­щик pbzip2 исполь­зует один мно­гони­тевой про­цесс из вось­ми нитей и зат­рачива­ет ≈24,4 с реаль­ного вре­мени на упа­ков­ку, при этом ≈1 мин 22,9 с (!) про­водит в поль­зователь­ском режиме и ≈1,8 с в режиме ядра. При­рост про­изво­дитель­нос­ти упа­ков­ки и, как следс­твие, сок­ращение вре­мени упа­ков­ки дос­тига­ются за счет нас­тояще­го парал­лель­ного выпол­нения нитей на нес­коль­ких про­цес­сорах (раз­ных ядрах про­цес­сора). Соот­ношение меж­ду реаль­ным вре­менем упа­ков­ки и сум­марно зат­рачен­ным вре­менем режима поль­зовате­ля, которое при­мер­но в 3 раза боль­ше, озна­чает исполь­зование в сред­нем трех про­цес­соров для парал­лель­ного выпол­нения вычис­литель­ных опе­раций упа­ков­ки.

Двойственность процессов и нитей Linux

Как ука­зыва­лось ранее, про­цес­сы и нити в ядре Linux сво­дят­ся к уни­вер­саль­ному понятию «задача». Задача, все ресур­сы которой (память, откры­тые фай­лы и т. д.) исполь­зуют­ся сов­мес­тно с дру­гими такими же задача­ми, явля­ется нитью. И наобо­рот, про­цес­сами явля­ются такие задачи, которые обла­дают набором сво­их час­тных, инди­виду­аль­ных ресур­сов.

Уни­вер­саль­ный сис­темный вызов clone поз­воля­ет ука­зать, какие ресур­сы ста­нут общи­ми в порож­даемой и порож­дающей задачах, а какие — час­тны­ми. Сис­темные вызовы порож­дения POSIX-про­цес­сов fork и POSIX-нитей pthread_create ока­зыва­ются в Linux все­го лишь «обер­тка­ми» над clone, что про­иллюс­три­рова­но в двух сле­дующих лис­тингах.

В пер­вом при­мере архи­ватор tar PID = 11801 соз­дает при помощи сис­темно­го вызова clone дочер­ний про­цесс PID = 11802, в который помеща­ет прог­рамму ком­прес­сора gzip, исполь­зуя сис­темный вызов execve. В резуль­тате парал­лель­ной работы двух вза­имо­дей­ству­ющих про­цес­сов будет соз­дан ком­прес­сирован­ный архив docs.tgz катало­га /usr/share/doc.

Сис­темный вызов clone — порож­дение нового про­цес­са

В при­мере из сле­дующе­го лис­тинга ком­прес­сор pbzip2 соз­дает при помощи сис­темно­го вызова clone семь «дочер­них» нитей ❶...❼ PID = 12514->12520, которые име­ют общую память CLONE_VM, общие откры­тые фай­лы CLONE_FILES и про­чие общие ресур­сы.

Сис­темный вызов clone — порож­дение новой нити

Дерево процессов

Про­цес­сы, попар­но свя­зан­ные дочер­не‑родитель­ски­ми отно­шени­ями, фор­миру­ют дерево про­цес­сов опе­раци­онной сис­темы. Пер­вый про­цесс init, называ­емый пра­роди­телем про­цес­сов, порож­дает­ся ядром опе­раци­онной сис­темы пос­ле ини­циали­зации и мон­тирова­ния кор­невой фай­ловой сис­темы, отку­да и счи­тыва­ется прог­рамма /sbin/init (в сов­ремен­ных сис­темах явля­ется сим­воличес­кой ссыл­кой на акту­аль­ный /lib/systemd/systemd). Пра­роди­тель про­цес­сов всег­да име­ет PID = 1, а его основной задачей явля­ется запуск раз­нооб­разных сис­темных служб, вклю­чая запуск обра­бот­чиков алфа­вит­но‑циф­рового тер­миналь­ного дос­тупа getty, менед­жера дис­пле­ев гра­фичес­кого дос­тупа, служ­бы дис­танци­онно­го дос­тупа SSH и про­чих (см. гла­ву 10). Кро­ме того, systemd наз­нача­ется при­емным родите­лем для «оси­ротев­ших» про­цес­сов, а так­же отсле­жива­ет ава­рий­ные завер­шения запус­каемых им служб и переза­пус­кает их.

В при­мере из сле­дующе­го лис­тинга показа­но дерево про­цес­сов, пос­тро­енное при помощи спе­циаль­ной коман­ды pstree, а в лис­тинге “Про­цес­сы ядра, демоны, прик­ладные про­цес­сы” — «клас­сичес­кое» пред­став­ление дерева про­цес­сов при помощи коман­ды ps.

Де­рево про­цес­сов

Про­цес­сы опе­раци­онной сис­темы при­нято клас­сифици­ровать на сис­темные (ядер­ные), де­моны и прик­ладные, исхо­дя из их наз­начения и свой­ств (см. лис­тинг “Про­цес­сы ядра, демоны, прик­ладные про­цес­сы”).

Прик­ладные про­цес­сы ❸ выпол­няют обыч­ные поль­зователь­ские прог­раммы (нап­ример, ути­литу man), для чего им выделя­ют инди­виду­аль­ную память, объ­ем которой ука­зан в стол­бце VSZ вывода коман­ды ps. Такие про­цес­сы обыч­но инте­рак­тивно вза­имо­дей­ству­ют с поль­зовате­лем пос­редс­твом управля­юще­го тер­минала (за исклю­чени­ем гра­фичес­ких прог­рамм), ука­зан­ного в стол­бце TTY.

Де­моны (daemons) ❷ выпол­няют сис­темные прог­раммы, реали­зующие те или иные служ­бы опе­раци­онной сис­темы. Нап­ример, cron реали­зует служ­бу пери­оди­чес­кого выпол­нения заданий, atd — служ­бу отло­жен­ного выпол­нения заданий, rsyslogd — служ­бу цен­тра­лизо­ван­ной жур­нализа­ции событий, sshd — служ­бу дис­танци­онно­го дос­тупа, systemd-udevd — служ­бу «регис­тра­ции» под­клю­чаемых устрой­ств, и т. д. Демоны запус­кают­ся на ран­них ста­диях заг­рузки опе­раци­онной сис­темы и вза­имо­дей­ству­ют с поль­зовате­лем не инте­рак­тивно при помощи тер­минала, а опос­редован­но — при помощи сво­их ути­лит. Таким обра­зом, отсутс­твие управля­юще­го тер­минала в стол­бце TTY отли­чает их от прик­ладных про­цес­сов.

Про­цес­сы ядра, демоны, прик­ладные про­цес­сы

Сис­темные (ядер­ные) ❶ про­цес­сы (gра­виль­нее — ядер­ные нити, т. к. выпол­няют­ся они в общей памяти ядра опе­раци­онной сис­темы) выпол­няют парал­лель­ные час­ти яд­ра опе­раци­онной сис­темы, поэто­му не обла­дают ни инди­виду­аль­ной вир­туаль­ной памятью VSZ, ни управля­ющим тер­миналом TTY. Более того, ядер­ные про­цес­сы не выпол­няют отдель­ную прог­рамму, заг­ружа­емую из ELF-фай­ла, поэто­му их име­на COMMAND явля­ются условны­ми и изоб­ража­ются в квад­ратных скоб­ках, а кро­ме того, они име­ют осо­бое сос­тояние I в стол­бце STAT.

Атрибуты процесса

Про­цесс в опе­раци­онной сис­теме явля­ется основным активным субъ­ектом, вза­имо­дей­ству­ющим с окру­жающи­ми его объ­екта­ми — фай­лами и фай­ловыми сис­темами, дру­гими про­цес­сами, устрой­ства­ми и пр. Воз­можнос­ти про­цес­са выпол­нять те или иные дей­ствия по отно­шению к дру­гим объ­ектам опре­деля­ются его спе­циаль­ными свой­ства­ми — атри­бута­ми про­цес­са.

Маркеры доступа

Воз­можнос­ти про­цес­са по отно­шению к объ­ектам, дос­туп к которым раз­гра­ничи­вает­ся при помощи дис­кре­цион­ных механиз­мов (в час­тнос­ти, к фай­лам дерева катало­гов) опре­деля­ются зна­чени­ями его атри­бутов, фор­миру­ющих его DAC-мар­кер дос­тупа, а имен­но — атри­бута­ми RUID, RGID, EUID, EGID, см. credentials.

Эф­фектив­ные иден­тифика­торы EUID (effective user identifier) и EGID (effective group identifier) ука­зыва­ют на «эффектив­ных» поль­зовате­ля и груп­пу, исполь­зующих­ся дис­кре­цион­ными механиз­мами для опре­деле­ния прав дос­тупа про­цес­са к фай­лам и дру­гим объ­ектам сог­ласно наз­начен­ному им режиму или спис­ку дос­тупа. Атри­буты RUID (real user identifier) и RGID (real group identifier) ука­зыва­ют на «нас­тоящих» поль­зовате­ля и груп­пу, «управля­ющих» про­цес­сом.

Пер­вому про­цес­су поль­зователь­ско­го сеан­са (в слу­чае регис­тра­ции в сис­теме
с исполь­зовани­ем алфа­вит­но‑циф­рового тер­минала — коман­дно­му интер­пре­тато­ру) наз­нача­ют атри­буты RUID/EUID и RGID/EGID рав­ными иден­тифика­торам зарегис­три­ровав­шегося поль­зовате­ля и его пер­вичной груп­пы. Пос­леду­ющие про­цес­сы поль­зователь­ско­го сеан­са нас­леду­ют зна­чения атри­бутов, т. к. порож­дают­ся в резуль­тате кло­ниро­вания при помощи fork. В при­мере из сле­дующе­го лис­тинга при помощи коман­ды id показа­ны зна­чения EUID/EGID поль­зователь­ско­го сеан­са и их нас­ледова­ние от коман­дно­го интер­пре­тато­ра, что явным обра­зом под­твержда­ет коман­да ps.

DAC-мар­кер дос­тупа про­цес­са — атри­буты RUID, EUID, RGID, EGID

Из­менение иден­тифика­торов EUID/EGID про­цес­са про­исхо­дит при сра­баты­вании механиз­ма неяв­ной переда­чи пол­номочий, осно­ван­ном на допол­нитель­ных атри­бутах SUID/SGID фай­лов прог­рамм. При запус­ке таких прог­рамм пос­редс­твом сис­темно­го вызова exec атри­буты EUID/EGID запус­кающе­го про­цес­са уста­нав­лива­ются рав­ными иден­тифика­торам UID/GID вла­дель­ца запус­каемой прог­раммы. В резуль­тате про­цесс, в который будет заг­ружена такая прог­рамма, будет обла­дать пра­вами вла­дель­ца прог­раммы, а не пра­вами поль­зовате­ля, запус­тивше­го эту прог­рамму.

В сле­дующем лис­тинге при­веден типич­ный при­мер исполь­зования механиз­ма неяв­ной переда­чи пол­номочий при выпол­нении команд passwd и wall. При сме­не пароля поль­зовате­лем при помощи прог­раммы /usr/bin/passwd ее про­цесс получа­ет необ­ходимое пра­во записи ① в файл /etc/shadow в резуль­тате переда­чи пол­номочий ❶ супер­поль­зовате­ля root (UID=0). При переда­че широко­веща­тель­ного сооб­щения всем поль­зовате­лям при помощи /usr/bin/wall необ­ходимо иметь пра­во записи ② в их фай­лы устрой­ств /dev/tty*, которое появ­ляет­ся ❷ в резуль­тате переда­чи пол­номочий груп­пы tty (GID = 5).

Ат­рибуты фай­ла SUID/SGID и атри­буты про­цес­са RUID, EUID, RGID, EGID

По отно­шению к объ­ектам, дос­туп к которым огра­ничи­вает­ся при помощи ман­датных механиз­мов, воз­можнос­ти про­цес­са опре­деля­ются зна­чени­ями его МАС‑мар­кера дос­тупа, а имен­но — атри­бутом ман­датной мет­ки LABEL. Как и RUID/EUID/RGID/EGID, атри­бут LABEL наз­нача­ется пер­вому про­цес­су сеан­са поль­зовате­ля явным обра­зом, а затем нас­леду­ется при кло­ниро­вании про­цес­сами‑потом­ками от про­цес­сов‑родите­лей. В при­мере из при­веден­ного ниже лис­тинга при помощи коман­ды id показан атри­бут LABEL сеан­са поль­зовате­ля, а при помощи коман­ды ps — его явное нас­ледова­ние от про­цес­са‑родите­ля.

Ана­логич­но изме­нени­ям EUID/EGID про­цес­са, про­исхо­дящим при запус­ке SUID-ной/SGID-ной прог­раммы, изме­нение мет­ки LABEL про­цес­са про­исхо­дит (сог­ласно ман­датным пра­вилам ❶) в сис­темном вызове exec при запус­ке прог­раммы, помечен­ной соот­ветс­тву­ющей ман­датной мет­кой фай­ла. Так, нап­ример, при запус­ке прог­раммы /usr/sbin/dhclient с типом dhcpc_exec_t ее ман­датной мет­ки ❸ про­цесс при­обре­тает тип dhcpc_t сво­ей ман­датной мет­ки ❹, в резуль­тате чего сущес­твен­но огра­ничи­вает­ся в пра­вах дос­тупа к раз­ным объ­ектам опе­раци­онной сис­темы.

MAC-мар­кер дос­тупа про­цес­са — ман­датная мет­ка selinux

Привилегии

Еще одним важ­ным атри­бутом про­цес­са, опре­деля­ющим его воз­можнос­ти по исполь­зованию сис­темных вызовов, явля­ются при­виле­гии про­цес­са cababilities. Нап­ример, обла­дание при­виле­гией CAP_SYS_PTRACE раз­реша­ет про­цес­сам трас­сиров­щиков strace и ltrace, исполь­зующих сис­темный вызов ptrace, трас­сировать про­цес­сы лю­бых поль­зовате­лей (а не толь­ко «свои», EUID которых сов­пада­ет с EUID трас­сиров­щика). Ана­логич­но, при­виле­гия CAP_SYS_NICE раз­реша­ет изме­нять при­ори­тет, уста­нав­ливать при­вяз­ку к про­цес­сорам и наз­начать алго­рит­мы пла­ниро­вания про­цес­сов и нитей лю­бых поль­зовате­лей, а при­виле­гия CAP_KILL раз­реша­ет посылать сиг­налы про­цес­сам лю­бых поль­зовате­лей.

Яв­ная при­виле­гия «вла­дель­ца» CAP_FOWNER поз­воля­ет про­цес­сам изме­нять режим и спис­ки дос­тупа, ман­датную мет­ку, рас­ширен­ные атри­буты и фла­ги любых фай­лов так, слов­но про­цесс выпол­няет­ся от лица вла­дель­ца фай­ла. При­виле­гия CAP_LINUX_IMMUTABLE раз­реша­ет управлять фла­гами фай­лов i, immutable и a, append, а при­виле­гия CAP_SETFCAP — уста­нав­ливать «фай­ловые» при­виле­гии запус­каемых прог­рамм.

Не­обхо­димо отме­тить, что имен­но обла­дание пол­ным набором при­виле­гий дела­ет поль­зовате­ля root (UID=0) в Linux супер­поль­зовате­лем. И наобо­рот, обыч­ный, неп­ривиле­гиро­ван­ный поль­зователь (в смыс­ле UID≠0) не обла­дает никаки­ми явны­ми при­виле­гиями (неяв­но он обла­дает при­виле­гией вла­дель­ца для всех сво­их объ­ектов). Наз­начение при­виле­гий про­цес­са (здесь допуще­но намерен­ное упро­щение механиз­ма нас­ледова­ния и наз­начения при­виле­гий при fork и exec без потери смыс­ла) про­исхо­дит при запус­ке прог­раммы при помощи сис­темно­го вызова exec, исполня­емый файл которо­го помечен «фай­ловыми» при­виле­гиями.

В при­мере из сле­дующе­го лис­тинга иллюс­три­рует­ся получе­ние спис­ка при­виле­гий про­цес­са при помощи ути­литы getpcaps. Как и ожи­далось, про­цесс postgres (PID=6711), работа­ющий от лица обыч­ного (неп­ривиле­гиро­ван­ного, в смыс­ле UID≠0) псев­дополь­зовате­ля postgres, не име­ет ❶ никаких при­виле­гий, а про­цесс apache2 (PID=10129), работа­ющий от лица супер­поль­зовате­ля root (UID=0), име­ет пол­ный ❷ набор при­виле­гий. Одна­ко про­цесс NetworkManager (PID=646) выпол­няет­ся от лица «супер­поль­зовате­ля», лишен­ного ❸ боль­шинс­тва сво­их при­виле­гий, т. к. ему их умыш­ленно умень­шили при его запус­ке (см. systemd в гла­ве 8) до минималь­но необ­ходимо­го набора, дос­таточ­ного для выпол­нения его фун­кций (xто спо­собс­тву­ет обес­печению защищен­ности опе­раци­онной сис­темы).

При­виле­гии (capabilities) про­цес­са

В лис­тинге ниже показан типич­ный при­мер при­мене­ния от­дель­ных при­виле­гий там, где клас­сичес­ки при­меня­ется неяв­ная переда­ча всех пол­номочий супер­поль­зовате­ля при помощи механиз­ма SUID/SGID. Нап­ример, «обыч­ная» ути­лита ping для выпол­нения сво­ей работы дол­жна соз­дать «необ­работан­ный» raw сетевой сокет, что явля­ется с точ­ки зре­ния ядра при­виле­гиро­ван­ной опе­раци­ей. В ста­рых сис­темах (акту­аль­но для Ubuntu до вер­сии 18.10 вклю­читель­но, начиная с 19.04 все уже «пра­виль­но из короб­ки») прог­рамма /bin/ping наделя­лась атри­бутом SUID ❶ и находи­лась во вла­дении супер­поль­зовате­ля root, чьи пра­ва и переда­вались при ее запус­ке. С точ­ки зре­ния защищен­ности сис­темы это не соот­ветс­тву­ет здра­вому смыс­лу, под­ска­зыва­юще­му наделять прог­раммы минималь­но необ­ходимы­ми воз­можнос­тями, дос­таточ­ными для их фун­кци­они­рова­ния. Для соз­дания «необ­работан­ных» raw и пакет­ных packet сокетов дос­таточ­но толь­ко при­виле­гии CAP_NET_RAW, а весь супер­поль­зователь­ский набор при­виле­гий более чем избы­точен.

Де­леги­рова­ние при­виле­гий прог­раммы ping

При отклю­чении переда­чи пол­номочий ❷ прог­рамма /bin/ping лиша­ется воз­можнос­ти выпол­нять свои фун­кции, а при наз­начении ей при помощи коман­ды setcap «фай­ловой» при­виле­гии CAP_NET_RAW ❸ фун­кци­ональ­ность воз­вра­щает­ся в пол­ном объ­еме, т. к. при­водит к уста­нов­ке «про­цес­сной» при­виле­гии CAP_NET_RAW при запус­ке этой прог­раммы. Для прос­мотра при­виле­гий, делеги­руемых при запус­ке прог­рамм, исполь­зует­ся пар­ная коман­да getcap.

Ана­логич­но, при исполь­зовании ана­лиза­торов сетево­го тра­фика tshark и/или wireshark, вызыва­ющих для зах­вата сетевых пакетов ути­литу dumpcap, тре­бует­ся откры­вать как «необ­работан­ные» raw, так и пакет­ные packet сетевые сокеты, что тре­бует той же при­виле­гии CAP_NET_RAW. Клас­сичес­кий спо­соб при­мене­ния ана­лиза­торов пакетов сос­тоит в исполь­зовании явной переда­чи всех пол­номочий супер­поль­зовате­ля (при помощи su или sudo) при их запус­ке, что опять не соот­ветс­тву­ет минималь­но необ­ходимым и дос­таточ­ным тре­бова­ниям к раз­решен­ным воз­можнос­тям прог­рамм.

Де­леги­рова­ние при­виле­гий прог­рамме tshark

Для эффектив­ного исполь­зования ана­лиза­торов тра­фика неп­ривиле­гиро­ван­ными поль­зовате­лями дос­таточ­но делеги­ровать их про­цес­сам зах­вата пакетов при­виле­гию CAP_NET_RAW при помощи «фай­ловых» при­виле­гий CAP_NET_RAW для прог­раммы зах­вата /usr/bin/dumpcap, что и про­иллюс­три­рова­но в пре­дыду­щем лис­тинге.

Другие атрибуты

Пе­ремен­ные окру­жения и текущий рабочий каталог на повер­ку тоже ока­зыва­ются атри­бута­ми про­цес­са, которые мож­но получить при помощи команд ps и pwdx соот­ветс­твен­но.

Пе­ремен­ные окру­жения про­цес­са

Те­кущий рабочий каталог про­цес­са