Czy analizowanie pliku / proc / jest bezpieczne?

Chcę przeanalizować /proc/net/tcp/, ale czy jest to bezpieczne?

Jak mam otwierać i czytać pliki z /proc/i nie bać się, że jakiś inny proces (lub sam system operacyjny) zmieni go w tym samym czasie?

Ogólnie nie. (Więc większość odpowiedzi jest błędnych.) To może być bezpieczne, w zależności od tego, jaką nieruchomość chcesz. Ale łatwo jest skończyć z błędami w swoim kodzie, jeśli za dużo zakładasz na temat spójności pliku w /proc. Na przykład zobacz ten błąd, który wynika z założenia, że /proc/mountsjest to spójna migawka .

Na przykład:

• /proc/uptimejest całkowicie atomowy , jak ktoś wspomniał w innej odpowiedzi - ale tylko od Linuksa 2.6.30 , który ma mniej niż dwa lata. Tak więc nawet ten mały, trywialny plik do tej pory podlegał warunkom wyścigu i nadal występuje w większości jąder korporacyjnych. Zobacz fs/proc/uptime.cbieżące źródło lub zatwierdzenie, które uczyniło je atomowym . Na jądrze starszym niż 2.6.30 możesz openplik, readkawałek, a jeśli później wrócisz i readznowu, otrzymany kawałek będzie niezgodny z pierwszym kawałkiem. (Właśnie to zademonstrowałem - spróbuj sam dla zabawy.)

• /proc/mountsjest atomowy w ramach pojedynczego readwywołania systemowego. Więc jeśli zbierzesz readcały plik naraz, otrzymasz jedną spójną migawkę punktów montowania w systemie. Jeśli jednak używasz kilku readwywołań systemowych - i jeśli plik jest duży, dokładnie to się stanie, jeśli użyjesz normalnych bibliotek I / O i nie zwrócisz szczególnej uwagi na ten problem - zostaniesz poddany wyścigowi stan: schorzenie. Nie tylko nie uzyskasz spójnej migawki, ale punkty montowania, które były obecne przed rozpoczęciem i nigdy nie przestały być obecne, mogą zniknąć w tym, co widzisz. Aby zobaczyć, że to atomowy dla jednego read(), spojrzenie m_start()nafs/namespace.c i zobaczyć go chwycić semafora że Osłony listy strumieni, które utrzymuje aż m_stop(), która jest wywoływana, gdyread()skończone. Aby zobaczyć, co może pójść nie tak, zobacz ten błąd z zeszłego roku (ten sam, do którego dołączyłem powyżej) w oprogramowaniu wysokiej jakości, które beztrosko czyta /proc/mounts.

• /proc/net/tcp, o którą tak naprawdę pytasz, jest jeszcze mniej spójne. Jest niepodzielna tylko w każdym wierszu tabeli . Aby to zobaczyć, przyjrzeć listening_get_next()sięnet/ipv4/tcp_ipv4.c i established_get_next()tuż poniżej w tym samym pliku i zobaczyć zamki biorą na każdej pozycji po kolei. Nie mam pod ręką kodu repro, aby zademonstrować brak spójności między wierszami, ale nie ma tam żadnych blokad (ani niczego innego), które sprawiłyby, że byłby spójny. Co ma sens, jeśli się nad tym zastanowić - praca w sieci jest często bardzo zajętą ​​częścią systemu, więc nie warto przedstawiać spójnego obrazu w tym narzędziu diagnostycznym.

Drugi kawałek, który utrzymuje /proc/net/tcpatomowej w zasięgu każdego wiersza jest buforowanie w seq_read(), co można przeczytać wfs/seq_file.c . Zapewnia to, że gdy już read()podzielisz jeden wiersz, tekst całego wiersza zostanie zachowany w buforze, dzięki czemu następny read()otrzyma resztę tego wiersza przed rozpoczęciem nowego. Ten sam mechanizm jest używany /proc/mountsdo zachowania atomowości każdego wiersza, nawet jeśli wykonujesz wiele read()wywołań, a także jest to mechanizm /proc/uptimeużywany w nowszych jądrach, aby zachować atomowość. Mechanizm ten nie buforuje całego pliku, ponieważ jądro jest ostrożne w kwestii wykorzystania pamięci.

Większość plików /procbędzie co najmniej tak spójna, jak /proc/net/tcpw każdym wierszu spójny obraz jednego wpisu we wszelkich dostarczanych informacjach, ponieważ większość z nich używa tej samej seq_fileabstrakcji. Jak /proc/uptimepokazuje przykład, niektóre pliki były nadal migrowane do użytku seq_filedopiero w 2009 roku; Założę się, że wciąż są takie, które wykorzystują starsze mechanizmy i nie mają nawet takiego poziomu atomowości. Te zastrzeżenia są rzadko udokumentowane. W przypadku danego pliku jedyną gwarancją jest odczytanie źródła.

W przypadku /proc/net/tcp, możesz go przeczytać i przeanalizować każdy wiersz bez obaw. Ale jeśli starają się wyciągać wnioski z wielu linii na raz - uważaj, inne procesy i jądro są zmieniając go podczas jej czytania, a ty pewnie tworząc błąd.

Chociaż pliki /procwyświetlane jako zwykłe pliki w przestrzeni użytkownika, nie są one naprawdę pliki, ale raczej podmioty, które obsługują standardowe operacje na plikach z przestrzeni użytkownika ( open, read, close). Zauważ, że jest to zupełnie inne niż posiadanie zwykłego pliku na dysku, który jest zmieniany przez jądro.

Wszystko, co robi jądro, to wypisuje swój stan wewnętrzny do swojej własnej pamięci za pomocą sprintffunkcji podobnej do tej, która jest kopiowana do przestrzeni użytkownika za każdym razem, gdy read(2)wywołujesz wywołanie systemowe.

Jądro obsługuje te wywołania w zupełnie inny sposób niż w przypadku zwykłych plików, co może oznaczać, że cała migawka danych, które przeczytasz, może być gotowa w momencie open(2), gdy to zrobisz , podczas gdy jądro zapewnia, że ​​jednoczesne wywołania są spójne i niepodzielne. Nigdzie tego nie czytałem, ale tak naprawdę nie ma sensu być inaczej.

Moja rada jest taka, aby przyjrzeć się implementacji pliku proc w swoim specyficznym dla Uniksa stylu. W rzeczywistości jest to kwestia implementacji (podobnie jak format i zawartość wyniku), która nie jest regulowana przez standard.

Najprostszym przykładem może być implementacja uptimepliku proc w Linuksie. Zwróć uwagę, jak cały bufor jest tworzony w funkcji wywołania zwrotnego dostarczonej do single_open.

/ proc to wirtualny system plików: w rzeczywistości daje wygodny wgląd w wewnętrzne elementy jądra. Przeczytanie go na pewno jest bezpieczne (dlatego jest tutaj), ale na dłuższą metę jest to ryzykowne, ponieważ wewnętrzne pliki wirtualnych plików mogą ewoluować wraz z nowszą wersją jądra.

EDYTOWAĆ

Więcej informacji znajduje się w dokumentacji proc w dokumencie jądra Linuksa , rozdział 1.4 Sieć Nie mogę znaleźć informacji, jak te informacje ewoluują w czasie. Myślałem, że jest zamrożony, ale nie mam jednoznacznej odpowiedzi.

EDYCJA2

Według Sco doc (nie linux, ale jestem prawie pewien, że wszystkie smaki * nix zachowują się tak)

Chociaż stan procesu i w konsekwencji zawartość plików / proc mogą zmieniać się z natychmiastowego na natychmiastowy, pojedyncze odczytanie (2) pliku / proc gwarantuje, że zwróci `` rozsądną '' reprezentację stanu, to znaczy odczyt będzie atomowa migawka stanu procesu. Żadna taka gwarancja nie ma zastosowania do kolejnych odczytów zastosowanych do pliku / proc dla działającego procesu. Ponadto atomowość nie jest w szczególności gwarantowana dla żadnego I / O zastosowanego do pliku as (przestrzeń adresowa); zawartość przestrzeni adresowej dowolnego procesu może być jednocześnie modyfikowana przez LWP tego procesu lub jakikolwiek inny proces w systemie.

API procfs w jądrze Linuksa zapewnia interfejs zapewniający, że odczyty zwracają spójne dane. Przeczytaj komentarze w __proc_file_read. Punkt 1) w dużym bloku komentarzy wyjaśnia ten interfejs.

To powiedziawszy, to oczywiście zależy od implementacji konkretnego pliku proc, aby poprawnie używać tego interfejsu, aby upewnić się, że zwracane dane są spójne. A więc odpowiadając na twoje pytanie: nie, jądro nie gwarantuje spójności plików proc podczas odczytu, ale zapewnia środki do implementacji tych plików w celu zapewnienia spójności.

Mam przydatne źródło dla Linuksa 2.6.27.8, ponieważ w tej chwili pracuję nad rozwojem sterowników w osadzonym celu ARM.

Na przykład plik ... linux-2.6.27.8-lpc32xx/net/ipv4/raw.cw linii 934 zawiera

    seq_printf(seq, "%4d: %08X:%04X %08X:%04X"
            " %02X %08X:%08X %02X:%08lX %08X %5d %8d %lu %d %p %d\n",
            i, src, srcp, dest, destp, sp->sk_state,
            atomic_read(&sp->sk_wmem_alloc),
            atomic_read(&sp->sk_rmem_alloc),
            0, 0L, 0, sock_i_uid(sp), 0, sock_i_ino(sp),
            atomic_read(&sp->sk_refcnt), sp, atomic_read(&sp->sk_drops));

które wyjścia

[wally@zenetfedora ~]$ cat /proc/net/tcp
  sl  local_address rem_address   st tx_queue rx_queue tr tm->when retrnsmt   uid  timeout inode                                                     
   0: 017AA8C0:0035 00000000:0000 0A 00000000:00000000 00:00000000 00000000     0        0 15160 1 f552de00 299
   1: 00000000:C775 00000000:0000 0A 00000000:00000000 00:00000000 00000000     0        0 13237 1 f552ca00 299
...

w funkcji, raw_sock_seq_show()która jest częścią hierarchii funkcji obsługujących procfs . Tekst nie jest generowany, dopóki plik nie read()zostanie złożony /proc/net/tcp, co jest rozsądnym mechanizmem, ponieważ odczyty procfs są z pewnością znacznie mniej powszechne niż aktualizowanie informacji.

Niektóre sterowniki (takie jak moje) implementują funkcję proc_read z pojedynczym plikiem sprintf(). Dodatkową komplikacją związaną z implementacją podstawowych sterowników jest obsługa potencjalnie bardzo długich danych wyjściowych, które mogą nie zmieścić się w pośrednim buforze przestrzeni jądra podczas pojedynczego odczytu.

Przetestowałem to z programem używającym bufora odczytu 64K, ale w moim systemie pojawił się bufor przestrzeni jądra o wielkości 3072 bajtów, aby proc_read mógł zwrócić dane. Aby otrzymać więcej niż tyle zwróconego tekstu, potrzeba wielu wywołań z zaawansowanymi wskaźnikami. Nie wiem, jaki jest właściwy sposób, aby zwracane dane były spójne, gdy potrzebne jest więcej niż jedno wejście / wyjście. Z pewnością każdy wpis /proc/net/tcpjest spójny. Istnieje pewne prawdopodobieństwo, że linie obok siebie są migawkami w różnym czasie.

Oprócz nieznanych błędów, nie ma warunków wyścigu /proc, które prowadziłyby do odczytu uszkodzonych danych lub mieszania starych i nowych danych. W tym sensie jest to bezpieczne. Jednak nadal istnieje warunek wyścigu, że wiele danych, z których czytasz, /procjest potencjalnie nieaktualnych, gdy tylko zostaną wygenerowane, a nawet bardziej, zanim zaczniesz je odczytywać / przetwarzać. Na przykład procesy mogą umrzeć w dowolnym momencie, a nowemu procesowi można przypisać ten sam pid; jedynymi identyfikatorami procesów, których możesz kiedykolwiek użyć bez warunków rasowych, są procesy własnego dziecka ”. To samo dotyczy informacji o sieci (otwarte porty itp.) I tak naprawdę większość informacji w formacie /proc. Uznałbym za złą i niebezpieczną praktykę poleganie na jakichkolwiek danych w formacie/procdokładność, z wyjątkiem danych dotyczących własnego procesu i potencjalnie jego procesów podrzędnych. Oczywiście nadal może być przydatne przedstawienie innych informacji od /procużytkownika / administratora do celów informacyjnych / logowania / itp. cele.

Kiedy czytasz z pliku / proc, jądro wywołuje funkcję, która została wcześniej zarejestrowana jako funkcja "odczytu" dla tego pliku proc. Zobacz __proc_file_readfunkcję w fs / proc / generic.c.

Dlatego bezpieczeństwo odczytu proc jest tak bezpieczne, jak funkcja wywoływana przez jądro w celu spełnienia żądania odczytu. Jeśli ta funkcja prawidłowo blokuje wszystkie dane, których dotyka i wraca do Ciebie w buforze, odczyt przy użyciu tej funkcji jest całkowicie bezpieczny. Ponieważ pliki proc, takie jak ten używany do spełniania żądań odczytu do / proc / net / tcp, istnieją już od jakiegoś czasu i przeszły skrupulatną recenzję, są tak bezpieczne, o jakie można prosić. W rzeczywistości wiele popularnych narzędzi Linuksa polega na czytaniu z systemu plików proc i formatowaniu danych wyjściowych w inny sposób. (Myślę, że „ps” i „netstat” to robią).

Jak zawsze, nie musisz wierzyć mi na słowo; możesz spojrzeć na źródło, aby uspokoić swoje obawy. Poniższa dokumentacja z proc_net_tcp.txt mówi ci, gdzie znajdują się funkcje "read" dla / proc / net / tcp, więc możesz spojrzeć na rzeczywisty kod, który jest uruchamiany, kiedy czytasz z tego pliku proc i sprawdzić samemu, że nie ma zagrożenia blokujące.

Ten dokument opisuje interfejsy / proc / net / tcp i / proc / net / tcp6.
Zauważ, że te interfejsy są przestarzałe na rzecz tcp_diag. Te interfejsy / proc dostarczają informacji o aktualnie aktywnych połączeniach TCP i są implementowane przez tcp4_seq_show () odpowiednio w net / ipv4 / tcp_ipv4.c i tcp6_seq_show () w net / ipv6 / tcp_ipv6.c.