Cindy Sridharan

1 ianuarie · 3 min citire

Cu ceva timp in urma, am scris despre modul in care descriptorii de fisiere pot fi transferati prin Unix Domain Sockets intre procese, atunci cand nu exista o relatie copil parinte intre cele doua procese. Unul dintre cazurile de utilizare pentru transferul descriptorului de fisiere intre procese este in timpul implementarii proxy-urilor de retea care gestioneaza traficul de intrare. Cu toate acestea, API-urile oferite de kernel pentru transferul descriptorului de fisiere intre procese au fost dificil de utilizat si pline de un numar de gotchas.

Array

In versiunile mai noi de Linux (5.6 si mai sus), exista un API mult mai bun pentru a atinge obiectivul mentionat anterior.

Un manual pentru procese

O instanta care ruleaza a unui program se numeste proces.

Array

Procesele se refera la utilizarea unui ID de proces (pid), care este un numar arbitrar ales de nucleu, de obicei limitat la 32768, dar pentru unele distributii, limita maxima este de 2²². Sistemului initial (launchd pe MacOS, systemd pe unele dintre distributiile Linux mai recente) i se atribuie pid 1.

Problema cu PID-urile

Una dintre problemele cu ID-urile de proces a fost faptul ca nu sunt unice.

Array

Sa presupunem ca exista un proces X cu pid 19448. Sa presupunem, de asemenea, ca exista un alt proces in sistem, procesul Y, care comunica cu procesul X referindu-se la pidul sau (cum ar fi pid de semnalizare 19448).

Daca acum procesul X ar trebui sa se incheie, acelasi pid 19448 ar putea fi reeditat de kernel la un alt proces Z, mai nou.

Aceasta se numeste reciclarea pid .

In acest moment, daca procesele Y semnalizeaza pid 19448, procesul Z va primi semnalul, nu procesul X caruia i s-a atribuit initial pid 19448.

Aceasta problema nu se limiteaza la semnale. Se aplica oricarui apel API / sistem care functioneaza cu pids. Exemple obisnuite includ kill, pkill si multe altele.

Probabil ca merita mentionat aici ca aceasta este o problema rezolvata in alte sisteme de operare, in special FreeBSD cu procdesc.

Ce este pidfd?

Spre deosebire de ID-ul procesului, care este orice numar intreg aleatoriu atribuit de nucleu, un pidfd este un descriptor de fisiere persistent care se refera la un alt proces. Ca si in cazul tuturor descriptorilor de fisiere, pidfds sunt private pentru procesul care a solicitat descriptorul de fisiere.

Apelul de sistem pidfd_open va permite procesului Y sa obtina un descriptor de fisier referitor la procesul X. O alta modalitate de a obtine acest descriptor de fisier este din / proc / pid_id. O alta modalitate de a obtine este prin setarea indicatorului CLONE_PIDFD pe apelul de sistem clona (2).

Odata ce procesul Y are un pidfd care se refera la procesul X, acesta poate folosi apelul de sistem pidfd_send_signal pentru a trimite un semnal la procesul X. Daca procesul X s-a incheiat deja, apelul pidfd_send_signal va esua cu eroarea ESRCH .

pidfd_getfd

Deci, un proces poate obtine un descriptor de fisier care se refera la un alt proces cu apelul de sistem pidfd_open. Dar acest lucru nu va ajuta la rezolvarea problemei de transfer a descriptorului de fisiere , in care un proces isi poate transfera / trimite descriptorii de fisiere catre un alt proces.

Acum, in timp ce / proc / pid / fd listeaza teoretic toate fisierele la care are acces un proces, nu listeaza descriptorii de fisiere care se refera la tevi (S_IFIFO), sockets (S_IFSOCK) sau alte obiecte care nu apar in ierarhia sistemului de fisiere .

In 2020, pe versiunile Linux 5.6 si mai sus, a fost adaugat un nou apel de sistem la Linux, care va permite unui proces sa obtina un duplicat al unui descriptor de fisier al unui alt proces mentionat de un pidfd cu apelul de sistem pidfd_getfd. Atat descriptorul fisierului, cat si duplicatul acestuia, impartasesc steagurile de stare ale fisierului si decalajul fisierului. Acest lucru se aplica tuturor tipurilor de fisiere, inclusiv fisierelor socket. Operatiile pe socket (cum ar fi bind (), recv (), sendmsg (), recvmsg ()) pot fi efectuate prin intermediul descriptorului de fisiere duplicat.

Efectiv, acest apel unic de sistem elimina API-urile incredibil de neintuitive si predispuse la erori pentru transferul descriptorului de fisiere intre procese prin socketuri de domeniu Unix, asa cum este descris in postarea mea anterioara.

Procesul de apelare trebuie sa aiba capacitatea de a apela ptrace (sau pentru a fi mai specific, verificarea modului de acces PTRACE_MODE_ATTACH_REALCREDS , care guverneaza permisiunea de a citi sau de a scrie intr-un alt proces) pe procesul tinta de la care doreste sa obtina copii duplicate ale fisierului descriptori.

Pentru un alt caz de utilizare mai concentrat asupra securitatii, pidfd si pidfd_getfd, postarea Seccomp Notify – New Frontiers in Unprivileged Container Development de Christian Brauner face o lectura foarte distractiva si informativa.

ARTICOLE SIMILAREDE LA ACELAȘI AUTOR